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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
