Re: transaction timeout

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: transaction timeout
Дата
Msg-id 17397.1122402784@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: transaction timeout  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: transaction timeout  (Martijn van Oosterhout <kleptog@svana.org>)
Список 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 по дате отправления:

Предыдущее
От: Dr NoName
Дата:
Сообщение: Re: transaction timeout
Следующее
От: wayne schlemitz
Дата:
Сообщение: ...