> 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