Re: POSIX shared memory redux

On Mon, Apr 11, 2011 at 3:11 PM, A.M. <agentm(at)themactionfaction(dot)com> wrote:
>
> On Apr 11, 2011, at 6:06 PM, Robert Haas wrote:
>
>> 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.  I was
>> imagining keeping some portion of the data in sysv shm, and moving the
>> big stuff to a POSIX shm that would operate alongside it.
>
> What do you mean by "leakier"? The goal here is to extinguish SysV shared memory for portability and convenience benefits. The mini-SysV proposal was implemented and shot down by Tom Lane.

I mean I'm not convinced that fcntl() locking will be as reliable.

I know Tom shot that down before, but I still think it's probably the
best way forward. The advantage I see is that we would be able to
more easily allocate larger chunks of shared memory with changing
kernel parameters, and perhaps even to dynamically resize shared
memory chunks. That'd be worth the price of admission even if we
didn't get all those benefits in one commit.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company