On Sat, Sep 13, 2003, Tom Lane wrote:
> David Schultz <dschultz@uclink.Berkeley.EDU> writes:
> > While looking into a block size mismatch problem between
> > Postgresql and FreeBSD's FFS, I noticed that postgresql is making
> > some rather odd-sized requests to malloc(3): 0x2034, 0x2020,
> > 0x4018, 0x8018, etc. Most malloc(3) implementations round large
> > allocations up to a multiple of a large power of 2---often the
> > hardware page size, so this is a pathological case for those
> > allocators.
>
> After looking more closely I saw that there were some corner cases where
> aset.c would unnecessarily switch from the intended power-of-two block
> sizes to non-power-of-two sizes. I've applied the attached fix.
Thanks for looking into this. I had meant to follow up sooner
myself, but I've been under time pressure lately. Your patch
looks good to me. I assume that pgsql will be able to use the
slack allocated in each chunk. I'll try my original test again
next weekend and let you know if this change clears up most of the
power-of-two-plus-epsilon issues I was seeing.