On Fri, Aug 15, 2014 at 12:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > * I think 5..8 are overly complex: we can just set SIGPIPE to SIG_IGN > (which is its usual setting in the postmaster already) and check for > EPIPE from the write().
wfm. > * There might be some benefit to swapping steps 9 and 10; at the > very least, this would eliminate the need to use O_NONBLOCK while > re-opening for read. Also wfm. > * We talked about combining this technique with a plain file lock > so that we would have belt-and-suspenders protection, in particular > something that would have a chance of working across NFS clients. > This would suggest leaving the fcntl lock in place, ie, don't do > step 11, and also that the file-to-be-locked *not* have any other > purpose (which would only increase the risk of losing the lock > through careless open/close). I'd be afraid that a secondary mechanism that mostly-but-not-really works could do more harm by allowing us to miss bugs in the primary, pipe-based locking mechanism than the good it would accomplish. >> Regular backends don't need to do anything special, except that they >> need to make sure that the file descriptor opened in step 8 gets >> inherited by the right set of processes. That means that the >> close-on-exec flag should be turned on in the postmaster; except in >> EXEC_BACKEND builds, where it should be turned off but then turned on >> again by child processes before they do anything that might fork. > > Meh. Do we really want to allow a new postmaster to start if there > are any processes remaining that were launched by backends? I'd > be inclined to just suppress close-on-exec, period. Seems like a pretty weird and artificial restriction. Anything that has done exec() will not be connected to shared memory, so it really doesn't matter whether it's still alive or not. People can and do write extensions that launch processes from PostgreSQL backends via fork()+exec(), and we've taken pains in the past not to break such cases. I don't see a reason to impose now (for no data-integrity-related reason) the rule that any such processes must not be daemons. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers