Re: lock timeout patch

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: lock timeout patch
Дата
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101AE99@Herge.rcsinc.local
обсуждение исходный текст
Ответ на lock timeout patch  (Satoshi Nagayasu <nagayasus@nttdata.co.jp>)
Ответы Re: lock timeout patch  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
> Tom,
>
> > I'd accept a mechanism to enforce a timeout at the lock level if you
> > could show me a convincing use-case for lock timeouts instead of
> > statement timeouts, but I don't believe there is one.  I think this
> > proposal is a solution in search of a problem.
>
> Hmmm ... didn't we argue this out with NOWAIT?   What did we conclude
> then?
> I'm reluctant to go over old ground repeatedly.

The result of this debate was that there was some use for it.  NOWAIT is
now implemented for table locking but not for row locking.

Personally I think there is some use for forcing transactions to abort
as soon as a lock situation is detected (although I probably wouldn't
use it).  For row level locking I would suggest to the original poster
to compare xmin/xmax (check the docs) to pre check the row level lock
condition.  This is inelegant but it mostly works.

FWIW, I think the treatment of locking in the docs could use some
improvement.  Especially wrt MVCC and pessimistic locking and the 'big
picture' issues going on there (especially why the former is better than
the latter).

Merlin


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Default libpq service
Следующее
От: "Andrew Dunstan"
Дата:
Сообщение: bounce messages