Robert Haas <robertmh...@gmail.com> writes: > On Sun, Apr 10, 2011 at 5:03 PM, A.M. <age...@themactionfaction.com> wrote: >> To ensure that no two postmasters can startup in the same data directory, I >> use fcntl range locking on the data directory lock file, which also works >> properly on (properly configured) NFS volumes. Whenever a postmaster or >> postmaster child starts, it acquires a read (non-exclusive) lock on the data >> directory's lock file. When a new postmaster starts, it queries if anything >> would block a write (exclusive) lock on the lock file which returns a >> lock-holding PID in the case when other postgresql processes are running.
> This seems a lot leakier than what we do now (imagine, for example, > shared storage) and I'm not sure what the advantage is. BTW, the above-described solution flat out doesn't work anyway, because it has a race condition. Postmaster children have to reacquire the lock after forking, because fcntl locks aren't inherited during fork(). And that means you can't tell whether there's a just-started backend that hasn't yet acquired the lock. It's really critical for our purposes that SysV shmem segments are inherited at fork() and so there's no window where a just-forked backend isn't visible to somebody checking the state of the shmem segment. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers