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
>
--
