Re: POSIX shared memory patch status - Mailing list pgsql-hackers

From A.M.
Subject Re: POSIX shared memory patch status
Date
Msg-id 559EE3A9-E83A-4140-A862-F782BA426D9F@themactionfaction.com
Whole thread Raw
In response to POSIX shared memory patch status  (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>)
Responses Re: POSIX shared memory patch status
List pgsql-hackers
On Jun 16, 2011, at 11:51 AM, Heikki Linnakangas wrote:

> What's the current state of the POSIX shared memory patch? I grabbed the patch from
http://archives.postgresql.org/message-id/D9EDACF7-53F1-4355-84F8-2E74CD19D22D@themactionfaction.comand it doesn't seem
toapply cleanly any more. Are you planning to continue working on it? 
>
> If I understood the conclusion of the discussions correctly, the current plan is to continue using a small SysV
sharedmemory segment for the interlock, and POSIX shared memory for the rest. That lets us stay below SHMMAX even if
it'ssmall, which is convenient for admins. Was there a conclusion on whether we should use fnctl() to provide some
extrasafety in the current interlock mechanism? I'm feeling that that should probably be split off to a separate patch,
itwould be easier to review separately. 

Hello,

Please try a merge from my github branch:

https://github.com/agentm/postgres/tree/posix_shmem

I don't believe any conclusions were reached because the debate concerned whether or not fcntl locking was sufficient.
Ithought so while others pointed out that the proposed interlock would not work with mutli-client NFSv3 despite the
factthat the current interlock doesn't either. 

I originally made the patch because SysV memory sometimes requires reboots which is especially annoying when expanding
anexisting production db server. Even if the next version of postgresql incorporates a hybrid SysV/POSIX shmem setup,
rebootsmay still be required if one runs any other processes requiring SysV shmem (such as older versions of
postgresql).

In any case, I lost interest in maintaining the patch and would not object to having the patch removed from the
CommitFest.

Cheers,
M

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Re: Patch - Debug builds without optimization
Next
From: Tom Lane
Date:
Subject: Re: Re: starting to review the Extend NOT NULL representation to pg_constraint patch