Re: DISCARD ALL (Again)

On Mon, Apr 21, 2014 at 12:00 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>
> * 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.
>

Doesn't makes sense implement a way to every extension register your own
cleanup code and them with DISCARD EXTENSIONS and/or DISCARD ALL run this
registered procedure?

If yes I can develop a patch to do that (actually I already start with
implementation).

Regards,

--
Fabrízio de Royes Mello
Consultoria/Coaching PostgreSQL
>> Timbira: http://www.timbira.com.br
>> Blog sobre TI: http://fabriziomello.blogspot.com
>> Perfil Linkedin: http://br.linkedin.com/in/fabriziomello
>> Twitter: http://twitter.com/fabriziomello