On Fri, Oct 21, 2016 at 8:29 AM, Peter Eisentraut <peter.eisentr...@2ndquadrant.com> wrote: > On 8/16/16 1:05 PM, Tom Lane wrote: >> Oh, interesting. It had occurred to me that we might be able to dodge >> this issue if we started to recommend using unnamed POSIX semaphores >> instead of SysV. (Obviously we'd want to check performance, but it's >> at least a plausible alternative.) I had not wanted to go there if >> it meant that we could have silent loss of SysV shmem with no other >> symptoms, because as I said upthread, I'm concerned about that breaking >> the multiple-postmaster interlock. However, if the cleanup kills only >> semaphores and not attached-to shmem, then that objection goes away and >> this becomes something we should seriously consider. > > I was digging around this issue the other day again. We have switched > to unnamed POSIX semaphores by default now, which will help. But for > dynamic shared memory (DSM) we use POSIX shared memory by default, which > is cleaned up without regarding to attachment. So there is still a > potential for failures here, possibly more rare or obscure, given the > usage of DSM.
The reason I did it that way is because System V shared memory is often subject to very low limits on how much can be allocated, which can also produce failures. It would be easy to switch the default implementation from POSIX to System V, but I suspect that would be a loser overall -- in other words, I suspect that if we switched the default, more people would get hosed by not being able to create those segments in the first place than are currently getting hosed by having them removed prematurely. Also, POSIX shared memory segments at least on Linux are implemented as files. If you remove a file, people who have it open can normally continue to access it. So it might work OK as long as the file isn't removed until after everybody involved in a parallel query has already attached. That's a dangerous thing to bet on, though, because the DSM facility also supports server-lifetime DSMs. We're not using those capabilities right now in core, but we might start - e.g. Magnus was suggesting that we could use DSMs plus Thomas Munro's DSA and DHT patches to replace the stats collector or the temp files used by pg_stat_statements. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers