Tom Lane wrote: > Bruce Momjian <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
