Re: pg_terminate_backend idea

Tom Lane wrote:
> "Magnus Hagander" <mha@sollentuna.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
treatedas  though the postmaster has paniced and shared memory might not be  cleaned up properly.  A new signal is
neededfor safe termination  because backends must first do a query cancel, then exit once they  have run the query
cancelcleanup 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@candle.pha.pa.us               |  (610)
359-1001+  If your life is a hard drive,     |  13 Roberts Road +  Christ can be your backup.        |  Newtown Square,
Pennsylvania19073