On 2015-05-20 20:38:51 -0400, Tom Lane wrote: > Jim Nasby <jim.na...@bluetreble.com> writes: > > On 5/20/15 6:56 PM, Andres Freund wrote: > >> On 2015-05-20 18:48:59 -0500, Jim Nasby wrote: > >>> and generally if you want to terminate the connection there's easier > >>> ways to do that then "SELECT pg_terminate_backend(pg_backend_pid())". > > >> Which would be what exactly? Say, you're inside a security definer > >> function. > > > Error isn't good enough so you want to kill the backend?
Yep. > > I hadn't considered that; what's the common use case for it? I've seen it basically in two cases: 1) The "role" of the server has changed in some way, and some function wants to force a reconnect. Say a former master that's now a logical replication (in that case IIRC londiste) standby, and a trigger was installed to rediredt existing writers. 2) A function detects that something has has gone rather wrong with a session state and wants to force a reconnect. I've seen this in a "handwritten" RLS implementation. > > ISTM it'd be better > > to allow elog to log and then terminate the backend, but of course that > > doesn't help with backwards compatibility. :/ > > That's spelled elog(FATAL), no? Which is, to my knowledge, inaccessible from at least plpgsql. I've a hard time believing it's actually a good idea to change this. It pretty much seems to only be useful if you're doing unqualified SELECT pg_cancel_backend(pid) FROM pg_stat_activity; type queries. I don't see that as something we need to address. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
