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) #
