Re: pg_terminate_backend

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_terminate_backend
Date: 2006-08-03 16:53:31
Message-ID: 44D22A0B.9000902@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Tom Lane wrote:
> Andreas Pflug <pgadmin(at)pse-consulting(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andreas Pflug 2006-08-03 16:53:51 Re: pg_terminate_backend
Previous Message Tom Lane 2006-08-03 16:50:45 Re: pg_terminate_backend