* Robert Haas (robertmh...@gmail.com) wrote: > On Fri, Apr 18, 2014 at 2:24 AM, Tom Lane <t...@sss.pgh.pa.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
signature.asc
Description: Digital signature