Reset plv8 for all sessions on a server about plv8 HOT 9 CLOSED

Sounds interesting.

Do you mean cleaning up of the current (single) session, or of all sessions 
currently available?

All, preferably. I haven't found another way to do this other than restart the 
entire db server.  

In a traditional web-app, only the app code needs to be restarted, but now that 
code lives in plv8 I need  way to signal it as well.  I've been looking at 
http://www.postgresql.org/docs/current/static/functions-admin.html#FUNCTIONS-ADM
IN-SIGNAL-TABLE and plan to experiment a bit tomorrow.

An added bonus to being able to signal just plv8 to restart would be to knock 
the process back down to it's startup memory size.

It would be best for the session to wait until it is not in a transaction and 
idle, which is what I'll be testing tomorrow by sending various signals to the 
process.

\c in psql does not reset the session - it starts a new connection. Instead of 
restarting the server you could have the app server close all its sessions and 
reconnect.

None of the PLs have the sort of functionality you are asking for, and AFAIK 
there is no provision for them to. I don't know of any hook that can be 
attached to a reset event, for example.

I guess it's not difficult to reset the JS context in the same session; c 
function plv8_reset() can clear the GlobalContext for the user.  I don't still 
see how to reset the other session's context, though.  IMHO it is possible in 
plv8 and I don't care the fact that other PLs don't have such way.

Of course we can provide such a function. But ISTM that what the OP wants is a 
way to do all this for all backends (or possibly some subset of backends, say 
those that are connected to a named database) from one command. Doing that is 
not going to be easy, as you say, and if it's to be doable I doubt that it can 
just be done by a single PL - it would almost certainly need core 
infrastructure to support it. But by all means start by providing a 
plv8_reset() function. As you say that should just reset the context for the 
calling user, and leave other contexts alone.

I ended using LISTEN/NOTIFY, new code deploys notify and clients disconnect and 
reconnect.  This still has issues, especially with things like pgbouncer.  This 
app is not running in production yet, and I'm curious as to whether postgres 
ever reuses a process on the server for reconnecting clients?

Anyways, a plv8_reset() would be cleaner and more intentional than a reconnect 
and can be propagated to all connected clients with LISTEN/NOTIFY at the app 
layer.

I have no idea of the pg internals, but if plv8 could tap into LISTEN/NOTIFY 
that would be very powerful as it would enable JSON/IPC as well as being able 
to hook js code to events.

I attempt to introduce plv8_reset() in the "resetfunc" branch.  Does it help 
your use case?  Or are you ok now with your LISTEN/NOTIFY solution?  I'm a 
little hesitant to add this function as Andrew concerned above, and there is 
not an easy way to dispatch this to all sessions anyway.

I'm not familiar with LISTEN/NOTIFY internal at the moment.  I'll study it.

Thanks so much for hacking on this.  LISTEN/NOTIFY has been working
great to get the clients to disconnect for an upgrade.   plv8_reset
seems to work great too, however my gut tells me that when we go to
production the "safest" method is going to be either restarting the
server or uninstall/reinstall plv8 (if the later is supported with
pg's transaction ddl then it's probably the way to go).

OK, then I defer my attempt to later development until we have good idea rather 
than making it dirty for now.