Re: Proposal to add a QNX 6.5 port to PostgreSQL

On Fri, Aug 15, 2014 at 12:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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