On Wed, Jul 30, 2014 at 11:02 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> So it seems like we could possibly go this route, assuming we can think
> of a variant of your proposal that's race-condition-free. A disadvantage
> compared to a true file lock is that it would not protect against people
> trying to start postmasters from two different NFS client machines --- but
> we don't have protection against that now. (Maybe we could do this *and*
> do a regular file lock to offer some protection against that case, even if
> it's not bulletproof?)
That's not a bad idea. By the way, it also wouldn't be too hard to
test at runtime whether or not flock() has first-close semantics. Not
that we'd want this exact design, but suppose you configure
shmem_interlock=flock in postgresql.conf. On startup, we test whether
flock is reliable, determine that it is, and proceed accordingly.
Now, you move your database onto an NFS volume and the semantics
change (because, hey, breaking userspace assumptions is fun) and try
to restart up your database, and it says FATAL: flock() is broken.
Now you can either move the database back, or set shmem_interlock to
some other value.
Now maybe, as you say, it's best to use multiple locking protocols and
hope that at least one will catch whatever the dangerous situation is.
I'm just trying to point out that we need not blindly assume the
semantics we want are there (or that they are not); we can check.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company