Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > Not having a way to kill backends is like having no way to kill a
> > process except rebooting the server.
>
> Some people think that making a database hard to kill is a good thing.
Sure. But we're not talking about taking down the whole database, we're
talking about taking down a connection.
Killing the database is the equivalent of killing the OS. It should be
hard to do either. But it should be easy to kill a process on an OS if
you have the right permissions, and similiarly it should be easy to kill
a connection to the database if you have the right permissions.
With respect to nested transactions and other things that might make
properly shutting down difficult, it seems to me that the SIGINT case is
actually a harder case to deal with. Why? Because for the SIGTERM case,
you basically have to do whatever is done whenever the connection itself
drops. If we can't handle the connection itself dropping out arbitrarily
then we have more serious problems than just how to handle SIGTERM. :-)
But for SIGINT you have to decide whether to just abort the innermost
transaction or the outermost one, and if it's the outermost one you have
to abort then you have to provide the mechanism for it -- something that
you might not have to deal with otherwise.
So it seems that handling SIGTERM might actually be easy: you have the
signal handler close the backend's side of the connection and let the
connection-dropping logic kick in automatically, no?
Thoughts? Am I completely off my rocker here? :-)
--
Kevin Brown kevin@sysexperts.com