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

From Simon Riggs
Subject Re: pgsql: Generational memory allocator
Date
Msg-id CANP8+j+qRwzU=2_FCteB=+Qo+gJwnBSNsq3+Rc+Dojqi9A23cw@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 07:06, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Meanwhile, over on
> https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=snapper&dt=2017-11-23%2013%3A56%3A17
>
> we have
>
> ccache gcc-4.7 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wmissing-format-attribute-Wformat-security -fno-strict-aliasing -fwrapv -fexcess-precision=standard -g -g -O2
-fstack-protector--param=ssp-buffer-size=4 -Wformat -Werror=format-security  -I../../../../src/include
-D_FORTIFY_SOURCE=2-D_GNU_SOURCE -I/usr/include/libxml2  -I/usr/include/mit-krb5  -c -o generation.o generation.c 
> generation.c: In function ‘GenerationContextCreate’:
> generation.c:206:7: error: static assertion failed: "padding calculation in GenerationChunk is wrong"
> make[4]: *** [generation.o] Error 1
>
> Looks to me like GenerationChunk imagines that 3*sizeof(pointer)
> must be a maxaligned quantity, which is wrong on platforms where
> MAXALIGN is bigger than sizeof(pointer).

Thanks, yes.

I can't see how to resolve that without breaking the design assumption
at line 122, "there must not be any padding to reach a MAXALIGN
boundary here!".

So I'll wait for Tomas to comment.

(I'm just about to catch a long flight, so will be offline for 24
hours, so we may need to revert this before I get back if it is
difficult to resolve.)

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


pgsql-committers by date:

Previous
From: Tomas Vondra
Date:
Subject: Re: pgsql: Generational memory allocator
Next
From: Andres Freund
Date:
Subject: Re: pgsql: Generational memory allocator