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 <tgl@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
