Re: [HACKERS] Unportable implementation of background worker start
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Unportable implementation of background worker start |
Дата | |
Msg-id | 26254.1492805635@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Unportable implementation of background worker start (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
Tom Lane <tgl@sss.pgh.pa.us> writes: > Andres Freund <andres@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
В списке pgsql-hackers по дате отправления: