Re: Dynamic Shared Memory stuff - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Dynamic Shared Memory stuff
Date
Msg-id CA+TgmoYwSGZNhBXt9s3_4DsVRyg8m2cZa8p0hD5vmUx5mT_OBw@mail.gmail.com
Whole thread Raw
In response to Re: Dynamic Shared Memory stuff  (Noah Misch <noah@leadboat.com>)
Responses Re: Dynamic Shared Memory stuff  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Wed, Jan 22, 2014 at 10:17 AM, Noah Misch <noah@leadboat.com> wrote:
> Yeah, abandoning the state file is looking attractive.

Here's a draft patch getting rid of the state file.  This should
address concerns raised by Heikki and Fujii Masao and echoed by Tom
that dynamic shared memory behaves differently than the main shared
memory segment.  The control segment ID is stored in the System V
shared memory block, so we're guaranteed that when using either System
V or POSIX shared memory we'll always latch onto the control segment
that matches up with the main shared memory segment we latched on to.
Cleanup for the file-mmap and Windows methods doesn't need to change,
because the former always just means clearing out $PGDATA/pg_dynshmem,
and the latter is done automatically by the operating system.

Comments?

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

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: GiST support for inet datatypes
Next
From: Andres Freund
Date:
Subject: Re: Create function prototype as part of PG_FUNCTION_INFO_V1