On 2013-12-10 18:12:53 -0500, Noah Misch wrote: > On Tue, Dec 10, 2013 at 07:50:20PM +0200, Heikki Linnakangas wrote: > > On 12/10/2013 07:27 PM, Noah Misch wrote: > > >On Thu, Dec 05, 2013 at 06:12:48PM +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.
Empathically seconded. > > > Another refinement is to wait for all the processes to attach before > > > setting > > > the segment's size with ftruncate(). That way, when the window is open for > > > leaking the segment, it's still 0-sized so leaking it is not a big deal. > > > >and it is less > > >general: not every use of DSM is conducive to having all processes attach > > >in a > > >short span of time. > > Let's cross that bridge when we get there. AFAICS it fits all the > > use cases discussed this far. The primary use case I have for dsm, namely writing extensions that can use shared memory without having to be listed in shared_preload_libraries, certainly wouldn't work in any sensible way with such a restriction. And I don't think that's an insignificant usecase. So I really fail to see what this would buy us. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
