From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: POSIX shared memory redux |
Date: | 2011-04-11 23:25:06 |
Message-ID: | 11177.1302564306@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Sun, Apr 10, 2011 at 5:03 PM, A.M. <agentm(at)themactionfaction(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | A.M. | 2011-04-11 23:29:41 | Re: POSIX shared memory redux |
Previous Message | Tom Lane | 2011-04-11 23:13:24 | Re: POSIX shared memory redux |