Robert Haas <> writes:
> On Sun, Apr 10, 2011 at 5:03 PM, A.M. <> 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 (
To make changes to your subscription:

Reply via email to