Re: pg_terminate_backend idea - Mailing list pgsql-hackers

From Tom Lane
Subject Re: pg_terminate_backend idea
Date
Msg-id 22571.1119411268@sss.pgh.pa.us
Whole thread Raw
In response to Re: pg_terminate_backend idea  (Bruce Momjian <pgman@candle.pha.pa.us>)
Responses Re: pg_terminate_backend idea
Re: pg_terminate_backend idea
List pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Tom Lane wrote:
>> In any case the correct way to solve the problem is to find out what's
>> being left corrupt by SIGTERM, rather than install more messiness in
>> order to avoid facing the real issue ...

> I am confused.  Are you talking about the client SIGTERM or the server? 

I am talking about Rod Taylor's reports that SIGTERM'ing individual
backends tends to lead to "lock table corrupted" crashes awhile later.
Now, I've been playing the part of Chicken Little on this for awhile,
but seeing an actual report of problems from the field certainly
strengthens my feelings about it.

What I think we need to do is find a way to isolate and fix the behavior
Rod is seeing.  It may be that the bug occurs only for SIGTERM, or it
may be that it's a general problem that a SIGTERM just increases the
probability of seeing.  In any case I think we have to solve it, not
create new mechanisms to try to ignore it.

> TODO has:

>     * Allow administrators to safely terminate individual sessions
>       Right now, SIGTERM will terminate a session, but it is treated as
>       though the postmaster has paniced and shared memory might not be
>       cleaned up properly.

That statement is entirely incorrect.
        regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Problem with dblink regression test
Next
From: Joe Conway
Date:
Subject: Re: Problem with dblink regression test