Re: pgsql: Generational memory allocator
От | Simon Riggs |
---|---|
Тема | Re: pgsql: Generational memory allocator |
Дата | |
Msg-id | CANP8+jJ+ECfzs80Fi11YgpEjRWAEEShkpiFkxNFu4AvA+M8QiA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: pgsql: Generational memory allocator (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | 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 по дате отправления: