On Mon, Dec 5, 2016 at 10:09 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Michael Paquier <michael.paqu...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
