Thread

1. Re: Improving backend startup interlock

   Giles Lean <giles@nemeton.com.au> — 2002-10-04T23:24:55Z

   Tom Lane writes:
   
   > $ 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 ...
   
   If only local locking is at issue then finding any one of fcntl()
   locking, flock(), or lockf() would do.  All Unixen will have one or
   more of these and autoconf machinery exists to find them.
   
   The issue Tom raised about NFS support remains: locking over NFS
   introduces new failure modes.  It also only works for NFS clients
   that support NFS locking, which not all do.
   
   Mind you NFS users are currently entirely unprotected from someone
   starting a postmaster on a different NFS client using the same data
   directory right now, which file locking would prevent. So there is
   some win for NFS users as well as local filesystem users.  (Anyone
   using NFS care to put their hand up?  Maybe nobody does?)
   
   Is the benefit of better local filesystem behaviour plus multiple
   client protection for NFS users who have file locking enough to
   outweigh the drawbacks?  My two cents says it is, but my two cents are
   worth approximately USD$0.01, which is to say not very much ...
   
   Regards,
   
   Giles
   
   

2. Re: Improving backend startup interlock

   Michael Paesold <mpaesold@gmx.at> — 2002-10-04T23:42:08Z

   Giles Lean <giles@nemeton.com.au> wrote:
   
   > Tom Lane writes:
   > 
   > > $ 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 ...
   > 
   > If only local locking is at issue then finding any one of fcntl()
   > locking, flock(), or lockf() would do.  All Unixen will have one or
   > more of these and autoconf machinery exists to find them.
   > 
   > The issue Tom raised about NFS support remains: locking over NFS
   > introduces new failure modes.  It also only works for NFS clients
   > that support NFS locking, which not all do.
   > 
   > Mind you NFS users are currently entirely unprotected from someone
   > starting a postmaster on a different NFS client using the same data
   > directory right now, which file locking would prevent. So there is
   > some win for NFS users as well as local filesystem users.  (Anyone
   > using NFS care to put their hand up?  Maybe nobody does?)
   > 
   > Is the benefit of better local filesystem behaviour plus multiple
   > client protection for NFS users who have file locking enough to
   > outweigh the drawbacks?  My two cents says it is, but my two cents are
   > worth approximately USD$0.01, which is to say not very much ...
   
   Well, I am going to do some tests with postgresql and our netapp
   filer later in October. If that setup proves to work fast and reliable
   I would also be interested in such a locking. I don't care about
   the feature if I find the postgresql/NFS/netapp-filer setup to be
   unreliable or bad performing.
   
   I'll see.
   
   Regards,
   Michael Paesold
   
   
   

3. Re: Improving backend startup interlock

   Joe Conway <mail@joeconway.com> — 2002-10-05T01:14:58Z

   Michael Paesold wrote:
   > Giles Lean <giles@nemeton.com.au> wrote:
   >>Mind you NFS users are currently entirely unprotected from someone
   >>starting a postmaster on a different NFS client using the same data
   >>directory right now, which file locking would prevent. So there is
   >>some win for NFS users as well as local filesystem users.  (Anyone
   >>using NFS care to put their hand up?  Maybe nobody does?)
   >>
   >>Is the benefit of better local filesystem behaviour plus multiple
   >>client protection for NFS users who have file locking enough to
   >>outweigh the drawbacks?  My two cents says it is, but my two cents are
   >>worth approximately USD$0.01, which is to say not very much ...
   > 
   > 
   > Well, I am going to do some tests with postgresql and our netapp
   > filer later in October. If that setup proves to work fast and reliable
   > I would also be interested in such a locking. I don't care about
   > the feature if I find the postgresql/NFS/netapp-filer setup to be
   > unreliable or bad performing.
   > 
   
   We have multiple Oracle databases running over NFS from an HPUX server to a 
   netapp and have been pleased with the performance overall. It does require 
   some tuning to get it right, and it hasn't been entirely without issues, but I 
   don't see us going back to local storage. We also just recently set up a Linux 
   box running Oracle against an NFS mounted netapp. Soon I'll be adding Postgres 
   on the same machine, initially using locally attached storage, but at some 
   point I may need to shift to the netapp due to data volume.
   
   If you do try Postgres on the netapp, please post your results/experience and 
   I'll do the same.
   
   Anyway, I guess I qualify as interested in an NFS safe locking method.
   
   Joe