I wrote:
> Andres Freund <and...@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 <t...@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 executed by 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
