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

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

> Giles Lean <giles@nemeton.com.au> writes:
> > Is there some reason that file locking is not acceptable?  Is there
> > any platform or filesystem supported for use with PostgreSQL which
> > doesn't have working exclusive file locking?
> 
> How would we know?  We have never tried to use such a feature.

I asked because I've not been following this project long enough to
know if it had been tried and rejected previously.  Newcomers being
prone to making silly suggestions and all that. :-)

> For sure I would not trust it on an NFS filesystem.  (Although we
> disparage running an NFS-mounted database, people do it anyway.)

<scratches head>

I can't work out if that's an objection or not.

I'm certainly no fan of NFS locking, but if someone trusts their NFS
client and server implementations enough to put their data on, they
might as well trust it to get a single lock file for startup right
too.  IMHO.  Your mileage may vary.

Regards,

Giles


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCHES] Cascaded Column Drop
Next
From: Tom Lane
Date:
Subject: Re: Improving backend startup interlock