On Apr 11, 2011, at 7:25 PM, Tom Lane wrote:

> 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.

Then you haven't looked at my patch because I address this race condition by 
ensuring that a lock-holding violator is the postmaster or a postmaster child. 
If such as condition is detected, the child exits immediately without touching 
the shared memory. POSIX shmem is inherited via file descriptors.

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to