Re: Improving backend startup interlock

Giles Lean <giles(at)nemeton(dot)com(dot)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