From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Magnus Hagander <magnus(at)hagander(dot)net> |
Cc: | Daniel Farina <daniel(at)heroku(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Noah Misch <noah(at)leadboat(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Cross-backend signals and administration (Was: Re: pg_terminate_backend for same-role) |
Date: | 2012-03-26 20:57:53 |
Message-ID: | 17594.1332795473@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Magnus Hagander <magnus(at)hagander(dot)net> writes:
> I wasn't aware that was the reason there. I think it was the general
> "leftovers" from previous times. When we first created
> pg_terminate_backend() there was a general thought that it might not
> be safe to just SIGTERM a backend to make it quit.
Not just "might not be safe" - it was demonstrably buggy in the
beginning.
> A bunch of fixes
> were put in place to make it more safe, but I'm not sure anybody
> actually declared it fully safe.
We never did, we only said we didn't know of more bugs.
> I'm not sure - perhaps we're past that worry these days?
I'm not. I still wouldn't trust SIGTERMing an individual backend in a
production database. It'll probably work, but what if it doesn't?
Best-case scenario is you'll need to do a panic shutdown to clear the
stuck lock or whatever that the backend left behind. (Once you've
diagnosed the problem, that is.) Now, in a case where the alternative
is a database shutdown anyway, you might as well try it. But it's the
kind of tool you only want to hand to responsible adults, which is why
it's superuser-only at the moment. I'm not sure we should be
encouraging people to fire that weapon indiscriminately.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Browne | 2012-03-26 21:28:27 | Re: Command Triggers, v16 |
Previous Message | Robert Haas | 2012-03-26 20:45:28 | Re: Command Triggers, v16 |