Re: Dynamic Shared Memory stuff

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