strange behaviour on pooled alloc
От | jwieck@debis.com (Jan Wieck) |
---|---|
Тема | strange behaviour on pooled alloc |
Дата | |
Msg-id | m108WVX-000EBPC@orion.SAPserv.Hamburg.dsh.de обсуждение исходный текст |
Ответы |
Re: [HACKERS] strange behaviour on pooled alloc
|
Список | pgsql-hackers |
Hi, I'm continuing with the pooled palloc() stuff and am stuck with a very strange thing. I've reverted my changes to palloc() and am doing all the memory block pool handling now in aset.c. The benefit from this will be that I later can easily make palloc() etc. macros. The new version of the AllocSet...() functions does not use ordered set. it manages the block pools itself. Has the same 10% speedup and I expect some more from the macro version of palloc(). It aligns small allocations to power of 2 for better reusability of free'd chunks which are held in 8 different free lists per alloc set depending on their size. It lost the ability of AllocSetDump() - who need's that? First I found some bad places where memory is used after it has been free'd. One was in the portal manager with a portal memory context struct! I'm pretty sure that I found all because I tested by memset() 'ing all memory on AllocSetFree() and AllocSetReset() with different values. The strange behaviour now is that depending on the blocksize and the limit for block/single alloction I use for the pools, the portals_p2 regression test fails or not. The failure is that the cursor foo24 does not return data if the pools blocksize is greater/equal 16K and the smallchunk limit is 2K. It returns the correct row if one of them is less. More irritating is that it only fails if run inside 'make runtest'. If I put multiple portals_p2 tests into the tests list, all fail the same. But if the test is run manually with the same psql switches, it succeeds. All this behaviour is identical on two Linux 2.1.88 installations. One has gcc-2.8.1 and glibc-2.0.13, the other gcc-2.7.2.1 and libc.5. I have absolutely no clue what's going on here. Anyone an idea how to track this down? Jan -- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #======================================== jwieck@debis.com (Jan Wieck) #
В списке pgsql-hackers по дате отправления: