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
flawin the design. More eyes would be welcome, of course.
https://github.com/agentm/postgres/tree/posix_shmem
Cheers,
M