Re: pg_terminate_backend idea

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: pg_terminate_backend idea
Date: 2005-06-22 03:34:28
Message-ID: 22571.1119411268@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2005-06-22 03:49:12 Re: Problem with dblink regression test
Previous Message Andrew Dunstan 2005-06-22 03:26:31 Re: Problem with dblink regression test