On Mon, Mar 26, 2012 at 4:57 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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.
I don't think we should be overly afraid of bugs in this code path. I
mean, there could very well be residual bugs, but that can be said of
anything. Moreover, if there are bugs, I'd like to find them and fix
them rather than living forever in a state of fear.
And frankly, if we're going to pick a feature to give the hairy
eyeball, this one wouldn't make my top ten list.
I think the more important question is a policy question: do we want
it to work like this? It seems like a policy question that ought to
be left to the DBA, but we have no policy management framework for
DBAs to configure what they do or do not wish to allow. Still, if
we've decided it's OK to allow cancelling, I don't see any real reason
why this should be treated differently.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
