Re: pgsql: Generational memory allocator - Mailing list pgsql-committers

From Simon Riggs
Subject Re: pgsql: Generational memory allocator
Date
Msg-id CANP8+jJ+ECfzs80Fi11YgpEjRWAEEShkpiFkxNFu4AvA+M8QiA@mail.gmail.com
Whole thread Raw
In response to Re: pgsql: Generational memory allocator  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
On 24 November 2017 at 09:04, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Andres Freund <andres@anarazel.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.)

Oh, OK, thanks.

It sunk in what was needed while flying, but that's better than my efforts.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-committers by date:

Previous
From: Dean Rasheed
Date:
Subject: pgsql: RLS comment fixes.
Next
From: Andrew Dunstan
Date:
Subject: Re: pgsql: Generational memory allocator