Re: POSIX shared memory patch status

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: POSIX shared memory patch status
Date: 2011-06-16 16:52:58
Message-ID: BANLkTin0Lfmui0u7cesjj+yjRaXUsmCS4Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jun 16, 2011 at 11:51 AM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> 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.com
> and it doesn't seem to apply 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 shared memory segment for the
> interlock, and POSIX shared memory for the rest. That lets us stay below
> SHMMAX even if it's small, which is convenient for admins.

+1, emphatically.

> Was there a
> conclusion on whether we should use fnctl() to provide some extra safety in
> the current interlock mechanism? I'm feeling that that should probably be
> split off to a separate patch, it would be easier to review separately.

+1 for a separate patch. I see no reason why fixing that's got to be
intertwined with this. It'd be relevant if we were planning to remove
the current POSIX shm interlock, but so far nobody has offered a
compelling explanation of why we should. The facility is supported
pretty much everywhere; it's just the size limit that's a problem.

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bernd Helmle 2011-06-16 16:56:17 Re: procpid?
Previous Message Tom Lane 2011-06-16 16:48:04 Re: use less space in xl_xact_commit patch