On Wed, Jul 30, 2014 at 11:02 AM, Tom Lane <t...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
