Re: Posix Shared Mem patch
От | A.M. |
---|---|
Тема | Re: Posix Shared Mem patch |
Дата | |
Msg-id | D156917A-248A-4C53-8B35-25E00B9454B8@themactionfaction.com обсуждение исходный текст |
Ответ на | Re: Posix Shared Mem patch (Daniel Farina <daniel@heroku.com>) |
Ответы |
Re: Posix Shared Mem patch
|
Список | 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 flawin the design. More eyes would be welcome, of course. https://github.com/agentm/postgres/tree/posix_shmem Cheers, M
В списке pgsql-hackers по дате отправления: