Re: [HACKERS] Unportable implementation of background worker start

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] Unportable implementation of background worker start
Дата
Msg-id 21444.1492798101@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] Unportable implementation of background worker start  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] Unportable implementation of background worker start
Список pgsql-hackers
I wrote:
> Andres Freund <andres@anarazel.de> writes:
>> On 2017-04-21 12:50:04 -0400, Tom Lane wrote:
>>> +#ifndef FD_CLOEXEC
>>> +#define FD_CLOEXEC 1
>>> +#endif

>> Hm? Are we sure this is portable?  Is there really cases that have
>> F_SETFD, but not CLOEXEC?

> Copied-and-pasted from our only existing use of FD_CLOEXEC, in libpq.

Looking closer, that code dates to 
   Author: Tom Lane <tgl@sss.pgh.pa.us>   Branch: master Release: REL8_0_BR [7627b91cd] 2004-10-21 20:23:19 +0000
   Set the close-on-exec flag for libpq's socket to the backend, to avoid   any possible problems from child programs
executedby the client app.   Per suggestion from Elliot Lee of Red Hat.
 

and while the public discussion about it

https://www.postgresql.org/message-id/flat/18172.1098382248%40sss.pgh.pa.us

doesn't really say, I suspect the specific coding was Elliot's suggestion
as well.  It probably had some value at one time ... 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.
        regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] Unportable implementation of background worker start
Следующее
От: Andres Freund
Дата:
Сообщение: Re: [HACKERS] Unportable implementation of background worker start