Re: pgsql: Generational memory allocator
От | Andres Freund |
---|---|
Тема | Re: pgsql: Generational memory allocator |
Дата | |
Msg-id | 20171123214636.unwkrkunr7m2bkii@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Generational memory allocator (Tomas Vondra <tv@fuzzy.cz>) |
Ответы |
Re: pgsql: Generational memory allocator
|
Список | pgsql-committers |
On 2017-11-23 22:34:57 +0100, Tomas Vondra wrote: > > I think it's a legitimate complaint that postmaster.log wasn't captured > > in this failure, but that's a buildfarm script oversight and hardly > > Andres' fault. > > > > Are the valgrind errors really written to postmaster log? I'm assuming it > failed because valgrind ran into an issue and killed the process. Yes. Search e.g. in https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skink&dt=2017-09-18%2004%3A10%3A01 for VALGRINDERROR-BEGIN. (You could argue that they're only written there in certain configurations, because I'd assume it'd not work in e.g. syslog configured systems, because valgrind just prints to stderr). > 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? Greetings, Andres Freund
В списке pgsql-committers по дате отправления: