Tom Lane <t...@sss.pgh.pa.us> writes:
> Andres Freund <and...@anarazel.de> writes:
>> On 2017-04-21 14:08:21 -0400, Tom Lane wrote:
>>> but I see that SUSv2
>>> mandates that fcntl.h provide both F_SETFD and FD_CLOEXEC, so by our own
>>> coding rules it ought to be okay to assume they're there. I'm tempted to
>>> rip out the quoted bit, as well as the #ifdef F_SETFD, from libpq and see
>>> if anything in the buildfarm complains.
>> +1
> Done, we'll soon see what happens.
Should have seen this coming, I guess: some of the Windows critters are
falling over, apparently because they lack fcntl() altogether. So the
#ifdef F_SETFD was really acting as a proxy for "#ifdef HAVE_FCNTL".
There's no HAVE_FCNTL test in configure ATM, and I'm thinking it would
be pretty silly to add one, since surely it would succeed on anything
Unix-y enough to run the configure script.
I'm guessing the best thing to do is put back #ifdef F_SETFD;
alternatively we might spell it like "#ifndef WIN32", but I'm unsure
if that'd do what we want on Cygwin or MinGW.
In non-Windows code paths in latch.c, we probably wouldn't need to
bother with #ifdef F_SETFD.
Hopefully we can leave in the removal of "#define FD_CLOEXEC".
Will wait a bit longer for more results.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
