Re: shared memory based stat collector (was: Sharing record typmods between backends)
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@2ndquadrant.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Dilip Kumar <dilipbalaut@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-14T16:24:20Z
Lists: pgsql-hackers
On 2017-08-14 12:21:30 -0400, Robert Haas wrote: > >> ... 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. Is there any platforms that require it? I thought posix, sysv and windows are sufficient? If we're going to start relying more on dsms we probably don't want to use mmap anyway... - Andres
Commits
-
Simplify autovacuum work-item implementation
- f2f9fcb3030b 10.0 landed
- 31ae1638ce35 11.0 landed
-
Fix error handling path in autovacuum launcher
- d9a622cee162 11.0 landed
- 870da1e1546c 10.0 landed
-
Dramatically reduce System V shared memory consumption.
- b0fc0df9364d 9.3.0 cited