Re: Improving backend startup interlock

Have people considered flock (advisory locking) on the postmaster.pid
file for backend detection? It has a nonblocking option. Don't most
OS's support it?

I can't understand why we can't get an easier solution to postmaster
detection than shared memory.

---------------------------------------------------------------------------

Tom Lane wrote:
> Giles Lean <giles(at)nemeton(dot)com(dot)au> writes:
> > I'm certainly no fan of NFS locking, but if someone trusts their NFS
> > client and server implementations enough to put their data on, they
> > might as well trust it to get a single lock file for startup right
> > too. IMHO. Your mileage may vary.
>
> Well, my local man page for lockf() sez
>
> The advisory record-locking capabilities of lockf() are implemented
> throughout the network by the ``network lock daemon'' (see lockd(1M)).
> If the file server crashes and is rebooted, the lock daemon attempts
> to recover all locks associated with the crashed server. If a lock
> cannot be reclaimed, the process that held the lock is issued a
> SIGLOST signal.
>
> and the lockd man page mentions that not only lockd but statd have to be
> running locally *and* at the NFS server.
>
> This sure sounds like file locking on NFS introduces additional
> failure modes above and beyond what we have already.
>
> Since the entire point of this locking exercise is to improve PG's
> robustness, solutions that depend on other daemons not crashing
> don't sound like a step forward to me. I'm willing to trust the local
> kernel, but I get antsy if I have to trust more than that.
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo(at)postgresql(dot)org
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073