Re: Improving backend startup interlock

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