Re: Improving backend startup interlock

From: Giles Lean <giles(at)nemeton(dot)com(dot)au>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Improving backend startup interlock
Date: 2002-10-04 23:24:55
Message-ID: 17431.1033773895@nemeton.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Curtis Faith 2002-10-04 23:32:49 fsync exlusive lock evidence WAS: Potential Large Performance Gain in WAL synching
Previous Message Neil Conway 2002-10-04 23:03:59 Re: Potential Large Performance Gain in WAL synching