Re: transaction timeout - Mailing list pgsql-general

From Tom Lane
Subject Re: transaction timeout
Date
Msg-id 17397.1122402784@sss.pgh.pa.us
Whole thread Raw
In response to Re: transaction timeout  (Scott Marlowe <smarlowe@g2switchworks.com>)
Responses Re: transaction timeout
List pgsql-general
Scott Marlowe <smarlowe@g2switchworks.com> writes:
> On Tue, 2005-07-26 at 12:41, Magnus Hagander wrote:
>> The only *safe* way to do it ATM is to restart the database. SIGTERM may
>> leave orphaned locks or such things in the system.

> Really?  I was under the impression that doing a "kill <backendpid>" on
> an idle connection would clean up those things.

Well, it ought to, but I for one don't consider that code path
adequately tested --- and we have seen at least one report (from Rod
Taylor if memory serves) suggesting that there are in fact bugs in it.

We know that SIGTERM'ing all the backends at once leaves the database
with a good state on disk; that path is tested everytime someone shuts
down Postgres.  It does not follow that SIGTERM'ing a single backend
leaves consistent state in shared memory.  Rod's report suggested a
corrupt lock table in particular.

> Was that a discussion on hackers that brought this up?  And if so,
> what was the time period, I'd like to read through it.

There was a flamewar late during the 8.0 devel cycle where someone was
pushing to add a SIGTERM-one-backend function, and I was demurring that
I didn't think it was adequately tested.  Subsequent events seem to have
proven that fear correct.

Eventually I'm sure we'll find and fix the problem, but at the moment
it's a risky thing to do.

            regards, tom lane

pgsql-general by date:

Previous
From: Dr NoName
Date:
Subject: Re: transaction timeout
Next
From: wayne schlemitz
Date:
Subject: ...