Re: pg_terminate_backend - Mailing list pgsql-hackers

From Andreas Pflug
Subject Re: pg_terminate_backend
Date
Msg-id 44D22A0B.9000902@pse-consulting.de
Whole thread Raw
In response to Re: pg_terminate_backend  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Andreas Pflug <pgadmin@pse-consulting.de> writes:
>   
>> Tom Lane wrote:
>>     
>>> No, you have that backwards.  The burden of proof is on those who want
>>> it to show that it's now safe.
>>>       
>
>   
>> If the backend's stuck, I'll have to SIGTERM it, whether there's
>> pg_terminate_backend or not.
>>     
>
> "Stuck?"  You have not shown us a case where SIGTERM rather than SIGINT
> is necessary or appropriate. 
Last night, I had a long-running query I launched from pgAdmin. It was
happily running and completing on the server (took about 2 hours), and
the backend went back to <IDLE>. pgAdmin didn't get back a response,
assuming the query was still running. Apparently, the VPN router had
interrupted the connection silently without notifying either side of the
tcp connection. Since the backend is <IDLE>, there's no query to cancel
and SIGINT won't help. So "Stuck" for me means a backend *not*
responding to SIGINT.
BTW, there's another scenario where SIGINT won't help. Imagine an app
running wild hammering the server with queries regardless of query
cancels (maybe some retry mechanism). You'd like to interrupt that
connection, i.e. get rid of the backend.

Regards,
Andreas



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pg_terminate_backend
Next
From: Andreas Pflug
Date:
Subject: Re: pg_terminate_backend