Re: DISCARD ALL (Again)

* Robert Haas (robertmhaas(at)gmail(dot)com) wrote:
> On Fri, Apr 18, 2014 at 2:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > 2. While I'm no Python expert, I believe GD is just a specific instance
> > of a general capability for global state in Python. Are we going to
> > promise that any and all user-created data inside Python goes away?
> > What about other PLs? Will users thank us if this suddenly starts
> > happening?
>
> This is not the first time that somebody's asked for a way to throw
> away global interpreter state, and I really think we ought to oblige.
> In a connection-pooling environment, you really need a way to get the
> connection back to its original state rather than some not-so-near
> facsimile thereof. Maybe it'll end up as an optional behavior, and
> which kind of reset to use will become part of the pooler
> configuration, but that doesn't bother me as much as not having it for
> those that want it.

Drop the connection and reconnect would be the answer to that. For as
much as we may hope and wish for a connection to go back to 'the way it
was upon first connection', throwing away the interpretor *might* (and I
wouldn't be comfortable claiming it absolutely..) get you there when
you've only called functions which use interpretors, but people write
code in C too and we've seen complaints of memory leaks, etc, from C
libraries and C extensions- and there's nothing we're going to be able
to do to address that, so this mythical 'DISCARD EVERYTHING' is a pipe
dream. (Were we to actually re-exec ourselves into a new process, as if
we went through a disconnect/reconnect, I'd be more inclined to support
this capability, but I'm not sure what such would really buy us...)

> What's a bit odd about this request is that it asks for the ability to
> throw away only part of the state. ISTM that if somebody wants to add
> that kind of capability, they ought to just package a function which
> does precisely that with the plpython extension, or create a Python
> function that zaps that particular variable if that's possible. I
> think it's clearly useful to have DISCARD ALL be a request to discard
> *everything* in one shot, but it's going to be a stretch to come up
> with DISCARD variants for every kind of partial state removal somebody
> wants to do.

Agreed.

Thanks,

Stephen