Thread

1. Re: Improving backend startup interlock

   Giles Lean <giles@nemeton.com.au> — 2002-09-29T02:58:53Z

   Tom Lane wrote:
   
   > Giles Lean <giles@nemeton.com.au> writes:
   > > Is there some reason that file locking is not acceptable?  Is there
   > > any platform or filesystem supported for use with PostgreSQL which
   > > doesn't have working exclusive file locking?
   > 
   > How would we know?  We have never tried to use such a feature.
   
   I asked because I've not been following this project long enough to
   know if it had been tried and rejected previously.  Newcomers being
   prone to making silly suggestions and all that. :-)
   
   > For sure I would not trust it on an NFS filesystem.  (Although we
   > disparage running an NFS-mounted database, people do it anyway.)
   
   <scratches head>
   
   I can't work out if that's an objection or not.
   
   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.
   
   Regards,
   
   Giles
   
   

2. Re: Improving backend startup interlock

   Tom Lane <tgl@sss.pgh.pa.us> — 2002-09-29T03:06:07Z

   Giles Lean <giles@nemeton.com.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
   
   

3. Re: Improving backend startup interlock

   Bruce Momjian <pgman@candle.pha.pa.us> — 2002-10-04T01:09:41Z

   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@nemeton.com.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@postgresql.org
   > 
   
   -- 
     Bruce Momjian                        |  http://candle.pha.pa.us
     pgman@candle.pha.pa.us               |  (610) 359-1001
     +  If your life is a hard drive,     |  13 Roberts Road
     +  Christ can be your backup.        |  Newtown Square, Pennsylvania 19073
   
   

4. Re: Improving backend startup interlock

   Tom Lane <tgl@sss.pgh.pa.us> — 2002-10-04T02:45:51Z

   Bruce Momjian <pgman@candle.pha.pa.us> writes:
   > Have people considered flock (advisory locking) on the postmaster.pid
   > file for backend detection?
   
   $ man flock
   No manual entry for flock.
   $
   
   HPUX has generally taken the position of adopting both BSD and SysV
   features, so if it doesn't exist here, it's not portable to older
   Unixen ...
   
   			regards, tom lane