Re: pgsql: Generational memory allocator

Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> On 11/23/2017 11:04 PM, Tom Lane wrote:
>> I pushed a patch that computes how much padding to add and adds it.
>> (It might not really work if size_t and void * are different sizes,
>> because then there could be additional padding in the struct; but
>> that seems very unlikely.)

> Thanks. Do we need to do something similar to the other memory contexts?
> I see Slab does not do this at all (assuming it's not necessary), and
> AllocSet does this in a different way (which seems a bit strange).

Hm ... the coding in AllocSet is ancient and I have to say that I don't
like it as well as what I put into generation.c. We could not have done
it in that way at the time, because (IIRC) we did not have constant macros
for SIZEOF_SIZE_T, and maybe not SIZEOF_VOID_P either --- and you need
constant macros in order to do the #if calculation, because sizeof() does
not work in preprocessor expressions. But we have 'em now, so I'm tempted
to change aset.c to match generation.c.

As for SlabChunk, I think that's fine as-is (except I wonder why the
"block" field is declared "void *" rather than "SlabBlock *"). Since
the contents are fixed at two pointer fields, it's impossible that
there's any unexpected padding in there --- the struct size is
basically guaranteed to be 2 * sizeof(pointer). Which makes it either 8
or 16 bytes, either one of which is certain to be a multiple of MAXALIGN.
So I think the StaticAssert that that's true is plenty sufficient in
that case.

regards, tom lane