Tom Lane wrote: > "Magnus Hagander" <[EMAIL PROTECTED]> 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@candle.pha.pa.us | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 8: explain analyze is your friend