Skip site navigation (1) Skip section navigation (2)

Re: Posix Shared Mem patch

From: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
To: Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Posix Shared Mem patch
Date: 2012-06-26 22:21:18
Message-ID: D156917A-248A-4C53-8B35-25E00B9454B8@themactionfaction.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On Jun 26, 2012, at 6:12 PM, Daniel Farina wrote:
> 
> (Emphasis mine).
> 
> I don't think that -hackers at the time gave the zero-shmem rationale
> much weight (I also was not that happy about the safety mechanism of
> that patch), but upon more reflection (and taking into account *other*
> software that may mangle shmem settings) I think it's something at
> least worth thinking about again one more time.  What killed the patch
> was an attachment to the deemed-less-safe stategy for avoiding bogus
> shmem attachments already in it, but I don't seem to recall anyone
> putting a whole lot of thought at the time into the zero-shmem case
> from what I could read on the list, because a small interlock with
> nattach seemed good-enough.
> 
> I'm simply suggesting that for additional benefits it may be worth
> thinking about getting around nattach and thus SysV shmem, especially
> with regard to safety, in an open-ended way.  Maybe there's a solution
> (like Robert's FIFO suggestion?) that is not too onerous and can
> satisfy everyone.


I solved this via fcntl locking. I also set up gdb to break in critical regions to test the interlock and I found no flaw in the design. More eyes would be welcome, of course.
https://github.com/agentm/postgres/tree/posix_shmem

Cheers,
M




In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2012-06-26 22:25:19
Subject: Re: Posix Shared Mem patch
Previous:From: Tom LaneDate: 2012-06-26 22:20:49
Subject: Re: Posix Shared Mem patch

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group