Re: tracking down idle transactions in pg_locks

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: tracking down idle transactions in pg_locks
Дата
Msg-id 10303.1216358082@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: tracking down idle transactions in pg_locks  (David Gardner <david@gardnerit.net>)
Список pgsql-novice
David Gardner <david@gardnerit.net> writes:
> Tom Lane wrote:
>> The most common cause of this problem is apps that issue "COMMIT; BEGIN"
>> and then go to sleep.  If that's what this app is doing (if you don't
>> know, turn on statement logging and find out...) then updating to a more
>> recent PG version might help.  In 8.3 a transaction doesn't block VACUUM's
>> row reclamation until it's done something more than just BEGIN.

> W are running 8.3,  I have been able to  reproduce the problem, it
> occurs after an insert has occurred.

Oh ... well that's just bad design :-(.  If the app goes to sleep with
an uncommitted insert then it's capable of blocking other transactions,
quite independently of VACUUM.  For instance, an attempt to insert a
conflicting unique-key value would have to block.

            regards, tom lane

В списке pgsql-novice по дате отправления:

Предыдущее
От: David Gardner
Дата:
Сообщение: Re: tracking down idle transactions in pg_locks
Следующее
От: "Ridvan Lakas ng Bayan S. Baluyos"
Дата:
Сообщение: Re: Stopping a transaction as soon as an error occurs