Re: Lock problem

Поиск
Список
Период
Сортировка
Искать
От
Alban Hertroys
Тема
Re: Lock problem
Дата
Msg-id
FAE7CF70-76F9-432F-9444-8DC859B99909@gmail.com
Ответ на
Re: Lock problem (Victor Sterpu)
Список
Дерево обсуждения
Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem Tom Lane <tgl@sss.pgh.pa.us>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem Merlin Moncure <mmoncure@gmail.com>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem Igor Neyman <ineyman@perceptron.com>
Re: Lock problem Merlin Moncure <mmoncure@gmail.com>
Re: Lock problem Alban Hertroys <haramrae@gmail.com>
Re: Lock problem Igor Neyman <ineyman@perceptron.com>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
Re: Lock problem Merlin Moncure <mmoncure@gmail.com>
Re: Lock problem "Victor Sterpu" <victor@caido.ro>
On 02 Apr 2014, at 20:13, Victor Sterpu  wrote:

> There may pass a few days or weeks until next lock.
> But I don't  undesrtand why the whole table is locked if there is one uncommited transaction.
> 
> The following scenario might be the cause:
> 1. Transaction is started
> 2. the client application is closed because of a power surge, the started transaction will never be commited
> 3. from the server point of view there is a unfinished transaction that will block future statements
> 
> Is this normal behaviour?

I’m pretty sure that with such a powersurge the connection gets closed, causing the transaction to roll back.

Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.


В списке pgsql-general по дате отправления
От: Rob Sargent
Дата:
От: Bret Stern
Дата:
Сообщение: Re: SSD Drives
FAQ