Re: transaction timeout

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: Magnus Hagander <mha(at)sollentuna(dot)net>, Dr NoName <spamacct11(at)yahoo(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: transaction timeout
Date: 2005-07-26 18:33:04
Message-ID: 17397.1122402784@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe <smarlowe(at)g2switchworks(dot)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

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message wayne schlemitz 2005-07-26 18:36:04
Previous Message Dr NoName 2005-07-26 18:25:45 Re: transaction timeout