Re: pgsql: Generational memory allocator

From: Tomas Vondra <tv(at)fuzzy(dot)cz>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andres Freund <andres(at)anarazel(dot)de>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: pgsql: Generational memory allocator
Date: 2017-11-23 22:51:03
Message-ID: ce281fac-b6f5-2d86-a9eb-4cc04d5d4bce@fuzzy.cz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

On 11/23/2017 11:04 PM, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)de> writes:
>> On 2017-11-23 22:34:57 +0100, Tomas Vondra wrote:
>>> Hmmm, I see. Presumably adding this to GenerationChunk (similarly to what we
>>> do in AllocChunkData) would address the issue:
>>>
>>> #if MAXIMUM_ALIGNOF > 4 && SIZEOF_VOID_P == 4
>>> Size padding;
>>> #endif
>>>
>>> but I have no way to verify that (no access to such machine). I wonder why
>>> SlabChunk doesn't need to do that (perhaps a comment explaining that would
>>> be appropriate?).
>
>> Can't you just compile pg on a 32bit system and manually define MAXALIGN
>> to 8 bytes?
>
> 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).

regards
Tomas

In response to

Responses

Browse pgsql-committers by date

  From Date Subject
Next Message Andres Freund 2017-11-24 01:19:16 pgsql: Fix handling of NULLs returned by aggregate combine functions.
Previous Message Tom Lane 2017-11-23 22:04:36 Re: pgsql: Generational memory allocator