Re: pg_terminate_backend idea

Tom Lane wrote:
> "Magnus Hagander" <mha(at)sollentuna(dot)net> writes:
> > But it still requires me to send some data (such as a dummy query) to
> > the backend before it exits. This is because server side libpq blocks
> > when reading and ignores signals at this time. I believe the fix for
> > this would be to pass a flag down to the libpq routines that we want to
> > be abort in case of signal+flag, set only when doing the "main call" to
> > recv, so we can kill idle process.
>
> Yech! That code is messy enough already, lets not pile another kluge
> atop it in order to handle something that's not even being requested
> AFAIR.
>
> In any case the correct way to solve the problem is to find out what's
> being left corrupt by SIGTERM, rather than install more messiness in
> order to avoid facing the real issue ...

I am confused. Are you talking about the client SIGTERM or the server?
I thought we agreed that using the cancel functionality, which we know
works and is tested, to do backend terminate was the right approach.
TODO has:

* Allow administrators to safely terminate individual sessions

Right now, SIGTERM will terminate a session, but it is treated as
though the postmaster has paniced and shared memory might not be
cleaned up properly. A new signal is needed for safe termination
because backends must first do a query cancel, then exit once they
have run the query cancel cleanup routine.

I don't see us ever able to handle backend terminate in any other way.
Are you complaining about the issue with terminating the client? I had
not considered that.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073