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 [EMAIL PROTECTED] > -- ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
