Re: Improving backend startup interlock - Mailing list pgsql-hackers

From Giles Lean
Subject Re: Improving backend startup interlock
Date
Msg-id 17431.1033773895@nemeton.com.au
Whole thread Raw
In response to Re: Improving backend startup interlock  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: Neil Conway
Date:
Subject: Re: Potential Large Performance Gain in WAL synching
Next
From: "Curtis Faith"
Date:
Subject: fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching