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