Re: Proposal to add a QNX 6.5 port to PostgreSQL

Robert, Tom, and others,

Glad to see good discussion and progress on the locking topic!

My proof of concept code (steps a though e below) avoided any reading or writing to the pipe (and associated handling of SIGPIPE), it just relied on postmaster open of PIPE with ENXIO to indicate all is clear.
Trying to keep things simple, I created 1 function for fcntl locks, 1 function for PIPE locks, and a wrapper that called both in sequence (wrapper is called by the Backend mains).
I agree that "d." could be omitted, but I thought better to be conservative and has all processes obtain fcntl and PIPE locks.
Is there a gap that a-e does not cover? (Sorry, not clear to me).

Postmaster :
a. get exclusive fcntl lock (to guard against race condition in PIPE-based lock)
b. check PIPE for any existing readers
+ fd_write = open(DIRECTORY_LOCK_PIPE, O_WRONLY | O_NONBLOCK);
+ if (!((fd_write < 0) && (errno == ENXIO))) ereport(FATAL,
+ if (fd_write > -1) close(fd_write);
c. open PIPE for read
+ fd_read = open(DIRECTORY_LOCK_PIPE, O_RDONLY | O_NONBLOCK);

All other backends:
d. get shared fcnlt lock
e. open PIPE for read
+ fd_read = open(DIRECTORY_LOCK_PIPE, O_RDONLY | O_NONBLOCK);

Just my 2 cents, I am happy with whatever solution you find agreeable.

My assumptions:
1. Platforms without System V shared memory (QNX) would use POSIX shared memory and file-based (fcntl+pipe) locks.
2. Existing platforms would continue to rely of System V shared memory and its proven locking by default (perhaps with option use all POSIX shared memory and file-based locks instead, at your discretion).

Robert, Assuming an algorithm choice is agreed upon in the near future, would you be the logical choice to implement the change?
I am happy to help, especially with any QNX-specific aspects, but don't want to step on anyone's toes.

Thanks.

Keith Baker

> -----Original Message-----
> From: Robert Haas [mailto:robertmhaas(at)gmail(dot)com]
> Sent: Friday, August 15, 2014 2:16 PM
> To: Tom Lane
> Cc: Baker, Keith [OCDUS Non-J&J]; pgsql-hackers(at)postgresql(dot)org
> Subject: Re: [HACKERS] 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