pgsql: Fix compiler warning for ppoll() on Cygwin

Peter Eisentraut <peter@eisentraut.org> writes:

Fix compiler warning for ppoll() on Cygwin
_GNU_SOURCE is required to get the prototype, so just define that
globally, as was already done in the linux template.

This seems to have broken lorikeet:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=lorikeet&amp;dt=2019-12-23%2006%3A38%3A29

================== pgsql.build/src/test/regress/regression.diffs ===================
diff -U3 /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out
--- /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/expected/create_function_1.out	2019-12-23 01:54:52.899453200 -0500
+++ /home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/results/create_function_1.out	2019-12-23 01:55:58.318974000 -0500
@@ -90,7 +90,7 @@
 ERROR:  only one AS item needed for language "sql"
 CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
     AS 'nosuchfile';
-ERROR:  could not access file "nosuchfile": No such file or directory
+ERROR:  could not access file "nosuchfile": ENOENT
 CREATE FUNCTION test1 (int) RETURNS int LANGUAGE C
     AS '/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll', 'nosuchsymbol';
 ERROR:  could not find function "nosuchsymbol" in file "/home/andrew/bf64/root/HEAD/pgsql.build/src/test/regress/regress.dll"

I'm guessing that this broke something in the #ifdef nest in
gnuish_strerror_r(), causing it to fail, causing pg_strerror_r()
to fall back to using get_errno_symbol().

regards, tom lane

I think the config.cache of lorikeet needs to be cleaned, because the
return type of strerror_r() has changed as a result of this commit, but
the build farm logs still show the old test result being used from the
cache.

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

On Thu, Dec 26, 2019 at 7:28 AM Peter Eisentraut <
peter.eisentraut@2ndquadrant.com> wrote:

I think the config.cache of lorikeet needs to be cleaned, because the
return type of strerror_r() has changed as a result of this commit, but
the build farm logs still show the old test result being used from the
cache.

I'll see what I can do. Connecting to it remotely (from Australia) is a fun
exercise ...

cheers

andrew

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

I think the config.cache of lorikeet needs to be cleaned, because the
return type of strerror_r() has changed as a result of this commit, but
the build farm logs still show the old test result being used from the
cache.

lorikeet's latest build run appears to have been done without config
cache, and it succeeded, so your guess was correct.

Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.

regards, tom lane

On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:

I think the config.cache of lorikeet needs to be cleaned, because the
return type of strerror_r() has changed as a result of this commit, but
the build farm logs still show the old test result being used from the
cache.

lorikeet's latest build run appears to have been done without config
cache, and it succeeded, so your guess was correct.

Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.

The problem with that is that a change in one template will cause the cache
to be invalidated for every buildfarm member. Maybe that doesn't matter too
much - after all we used not to keep the cache at all.

cheers

andrew

Andrew Dunstan <andrew@dunslane.net> writes:

On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.

The problem with that is that a change in one template will cause the cache
to be invalidated for every buildfarm member. Maybe that doesn't matter too
much - after all we used not to keep the cache at all.

I don't think we change those templates often enough for that to be
much of a concern. Trying to make the buildfarm script smart enough
to check only the relevant template seems like more trouble than it'd
be worth.

regards, tom lane

On Fri, Dec 27, 2019 at 10:24 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Andrew Dunstan <andrew@dunslane.net> writes:

On Thu, Dec 26, 2019 at 4:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Next question is why the buildfarm client got that wrong. Seems like
its accache logic needs to notice changes in src/template/* as well as
the configure script proper.

The problem with that is that a change in one template will cause the cache
to be invalidated for every buildfarm member. Maybe that doesn't matter too
much - after all we used not to keep the cache at all.

I don't think we change those templates often enough for that to be
much of a concern. Trying to make the buildfarm script smart enough
to check only the relevant template seems like more trouble than it'd
be worth.

Right, fix along these lines committed, will be in the next release.

cheers

andrew

--
Andrew Dunstan https://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services