Re: [COMMITTERS] pgsql: Introduce dynamic shared memory areas.

On Mon, Dec 5, 2016 at 10:09 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Michael Paquier <michael(dot)paquier(at)gmail(dot)com> writes:
>> This commit is generating a warning when compiling on my Win7 dev box:
>
> dromedary has this:
>
> ccache gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv -g -O2 -ansi -I../../../../src/include -DCOPY_PARSE_PLAN_TREES -DRAW_EXPRESSION_COVERAGE_TEST -c -o network_selfuncs.o network_selfuncs.c
> dsa.c: In function 'dsa_dump':
> dsa.c:1106: warning: format '%016lx' expects type 'long unsigned int', but argument 3 has type 'dsa_pointer'
> dsa.c:1106: warning: format '%016lx' expects type 'long unsigned int', but argument 4 has type 'dsa_pointer'
> dsa.c: In function 'make_new_segment':
> dsa.c:2039: warning: left shift count >= width of type
> dsa.c:2039: warning: left shift count >= width of type
> dsa.c:2077: warning: left shift count >= width of type
>
> The first two of those should be fixed by 670b3bc8f, but the shift
> problems remain.

Thanks. I think I see what's happening here. DSA_MAX_SEGMENT_SIZE is
defined as ((size_t) 1 << DSA_OFFSET_WIDTH). I'm not sure why that's
not (Size), but the issue is that any system with 64-bit atomics
support ends up selecting the 64-bit version of DSA even if Size is
32-bit. So DSA_OFFSET_WIDTH ends up as 40, and then the wheels come
off. I think I'll go adjust things so that we always pick the 32-bit
version of DSA if Size is 32-bits. There's some theoretical loss
there since we are then limited to 32 DSA segments per DSA area and
hypothetically you could want more than that, but I don't think that's
much of a problem in practice because you probably would run out of
address space before you hit 32 segments anyway.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company