On Mon, Apr 21, 2014 at 12:00 AM, Stephen Frost <[email protected]> wrote: > > * Robert Haas ([email protected]) wrote: > > On Fri, Apr 18, 2014 at 2:24 AM, Tom Lane <[email protected]> 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
