Noah Misch <n...@leadboat.com> writes: > On Tue, Dec 10, 2013 at 07:50:20PM +0200, Heikki Linnakangas wrote: >> Let's not add more cases like that, if we can avoid it.
> Only if we can avoid it for a modicum of effort and feature compromise. > You're asking for PostgreSQL to reshape its use of persistent resources so you > can throw around "killall -9 postgres; rm -rf $PGDATA" without so much as a > memory leak. That use case, not PostgreSQL, has the defect here. The larger point is that such a shutdown process has never in the history of Postgres been successful at removing shared-memory (or semaphore) resources. I do not feel a need to put a higher recoverability standard onto the DSM code than what we've had for fifteen years with SysV shmem. But, by the same token, it shouldn't be any *less* recoverable. In this context that means that starting a new postmaster should recover the resources, at least 90% of the time (100% if we still have the old postmaster lockfile). I think the idea of keeping enough info in the SysV segment to permit recovery of DSM resources is a good one. Then, any case where the existing logic is able to free the old SysV segment is guaranteed to also work for DSM. regards, tom lane -- Sent via pgsql-hackers mailing list (email@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers