Re: [HACKERS] Unportable implementation of background worker start
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Unportable implementation of background worker start |
Дата | |
Msg-id | 30882.1492800880@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Unportable implementation of background worker start (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: [HACKERS] Unportable implementation of background worker start
|
Список | pgsql-hackers |
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. In the same area, I noticed that POSIX does not say that the success result for fcntl(F_SETFD) and related cases is 0. It says that the failure result is -1 and the success result is some other value. We seem to have this right in most places, but e.g. port/noblock.c gets it wrong. The lack of field complaints implies that just about everybody actually does return 0 on success, but I still think it would be a good idea to run around and make all the calls test specifically for -1. regards, tom lane
В списке pgsql-hackers по дате отправления: