From: | Simon Riggs <simon(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tomas Vondra <tv(at)fuzzy(dot)cz>, pgsql-committers <pgsql-committers(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net> |
Subject: | Re: pgsql: Generational memory allocator |
Date: | 2017-11-24 14:29:52 |
Message-ID: | CANP8+jJ+ECfzs80Fi11YgpEjRWAEEShkpiFkxNFu4AvA+M8QiA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
On 24 November 2017 at 09:04, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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.)
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
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2017-11-24 15:35:43 | Re: pgsql: Generational memory allocator |
Previous Message | Dean Rasheed | 2017-11-24 14:19:50 | pgsql: RLS comment fixes. |