From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Function to kill backend |
Date: | 2004-04-03 01:06:34 |
Message-ID: | 10110.1080954394@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> Tom Lane wrote:
>> it would definitely need to be a lot more constrained than
>> send-any-signal-to-any-postgres-process ... even for a superuser,
>> that's a mighty fat-gauge foot-gun.
> What sort of constraints do you have in mind?
I'd limit it to SIGINT (query cancel) and SIGTERM (fast shutdown),
and I'm not even real sure about SIGTERM. That facility is designed to
work in the case of shutting down all backends together --- I'm not sure
I want to promise that it behaves pleasantly to SIGTERM one backend and
leave the rest going. Nor do I see a real good use-case for it.
Also, no killing processes that aren't regular backends (eg, the
bgwriter, the stats processes, and most especially the postmaster).
Another point is that killing by PID is not necessarily what you want to
do --- kill by transaction ID might be a better API, especially for
query-cancel cases.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Koizar | 2004-04-03 01:09:51 | Re: [GENERAL] Large DB |
Previous Message | Tom Lane | 2004-04-03 00:57:47 | Re: [GENERAL] Large DB |