> On Fri, Feb 04, 2005 at 01:44:10PM -0600, Thomas F.O\'Connell wrote: > > Is there any stronger medicine that\'s available (for instance, when a > > backend won\'t respond to SIGTERM) and has no unfortunate side effects? > > I just ran into this situation the other day (and made the unfortunate > > discovery that SIGABRT is as bad as SIGKILL as far as a postmaster is > > concerned). > > As soon as a backend dies a unnatural death, postmaster will rightly > consider that it may have corrupted the shared state. In turn > postmaster will kill all its children mercilessly so they don\'t spread > the disease. > > Even SIGTERM can have bad consequences if it arrives at the wrong time. > (That\'s why a function to close a remote connection was rejected.) > > So, short answer: no. This could be better than what is however. Management would be easier if there was a way to trigger a series of behaviors on a given signal to a child: The child (1) cancels and rollbacks any transactions it has open, (2) enters a mode where it attempts to communicate with the client and failing so does an orderly connection close. I would never go back to them, but I can say that the Sybase SQL Studio servers where much easier to manage in this regard. If you are not very careful about how you handle orphaned connections in Postgres you will likely lose data....not "maybe" like a long shot...but "likely". I suppose if your data is fairly static (e.g. website cms) then this would not happen often, but anything with a lot of tansactions it will. The best protection is to do extensive testing with any application you use or develop, but that\'s not possible for everyone to do a sufficient amount of testing to avoid some of these issues. If I was submitting patches for Postgres I\'d push a little harder, and if I were, this problem would be at the top of my list as things to fix in Postgres. Best regards, Jim Wilson ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
