Nice algorithm. On Fri, Aug 15, 2014 at 02:16:08PM -0400, Robert Haas wrote: > On Fri, Aug 15, 2014 at 12:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > > * 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.
Users do corrupt their NFS- and GFS2-hosted databases today. I would rather have each process hold only an fcntl() lock than hold only the FIFO file descriptor. There's no such dichotomy, so let's have both. > > 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. +1 -- Noah Misch EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
