Re: pg_terminate_backend idea - Mailing list pgsql-hackers

From Rod Taylor
Subject Re: pg_terminate_backend idea
Date
Msg-id 1119412849.712.179.camel@home
Whole thread Raw
In response to Re: pg_terminate_backend idea  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, 2005-06-21 at 23:34 -0400, Tom Lane wrote:
> 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.

If it helps, it seems to occur primarily (perhaps always) when there are
schema changes being performed when the SIGTERM is issued.

I don't remember seeing them on Intel or on v7.2 (we didn't stay on 7.4
very long), but on a fairly well loaded Solaris machine (v880 with
between 100 and 200 connections) it happens enough that we automatically
schedule a server restart during the first opportunity when we need to
kill connections in this way This is generally when the server doesn't
recognize the client has dropped -- pgpool can be clumsy with
connections).

> > 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
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 1: subscribe and unsubscribe commands go to majordomo@postgresql.org
> 
-- 



pgsql-hackers by date:

Previous
From: "Andrew Dunstan"
Date:
Subject: Re: pl/pgsql: END verbosity
Next
From: "Andrew Dunstan"
Date:
Subject: Re: Problem with dblink regression test