On Fri, Apr 3, 2020 at 8:18 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > BTW, some of the buildfarm is showing a simpler portability problem: > they think you were too cavalier about the difference between time_t > and pg_time_t. (On a platform with 32-bit time_t, that's an actual > bug, probably.) lapwing is actually failing: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lapwing&dt=2020-04-03%2021%3A41%3A49 > > ccache gcc -std=gnu99 -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Werror=vla -Wendif-labels > -Wmissing-format-attribute -Wformat-security -fno-strict-aliasing -fwrapv > -fexcess-precision=standard -g -O2 -Werror -I. -I. -I../../../src/include > -DENFORCE_REGRESSION_TEST_NAME_RESTRICTIONS -D_GNU_SOURCE > -I/usr/include/libxml2 -I/usr/include/et -c -o basebackup.o basebackup.c > basebackup.c: In function 'AddFileToManifest': > basebackup.c:1199:10: error: passing argument 1 of 'pg_gmtime' from > incompatible pointer type [-Werror] > In file included from ../../../src/include/access/xlog_internal.h:26:0, > from basebackup.c:20: > ../../../src/include/pgtime.h:49:22: note: expected 'const pg_time_t *' but > argument is of type 'time_t *' > cc1: all warnings being treated as errors > make[3]: *** [basebackup.o] Error 1 > > but some others are showing it as a warning. > > I suppose that judicious s/time_t/pg_time_t/ would fix this.
I think you sent this email just after I pushed db1531cae00941bfe4f6321fdef1e1ef355b6bed, or maybe after I'd committed it locally and just before I pushed it. If you prefer a different fix than what I did there, I can certainly whack it around some more. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
