On Mon, Aug 14, 2017 at 12:16 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Robert Haas <robertmh...@gmail.com> writes: >> On Sun, Aug 13, 2017 at 9:59 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> In principle we could keep the existing mechanism as a fallback. >>> Whether that's worth the trouble is debatable. The current code >>> in initdb believes that every platform has some type of DSM support >>> (see choose_dsm_implementation). Nobody's complained about that, >>> and it certainly works on every buildfarm animal. So for all we know, >>> dynamic_shared_memory_type = none is broken already. > >> Actually, now that you mention it, I think it *is* broken already, or >> more to the point, if you configure that value, the autovacuum >> launcher hangs up, because of the AutovacuumWorkItem stuff that Alvaro >> added. When I just tested it, the AV launcher somehow ended up >> waiting for AutovacuumLock and I had to SIGQUIT the server to shut it >> down. > > Hmm, shouldn't that be an open item for v10?
I already added it. >> ... If somebody has a system where no other form of shared >> memory, works dynamic_shared_memory_type = mmap is still a thing, so >> the use case for "none" seems very thin indeed. I'd vote for just >> ripping it out in v11. > > Just FYI, the only values being reported by buildfarm animals are > "posix", "sysv", and "windows". So while mmap may be a thing, > it's an untested thing. I'm pretty sure I dev-tested it before committing anything, but, certainly, having ongoing BF coverage woudn't be a bad thing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers