Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Дата
Msg-id 24300.1101355260@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  (Bruce Momjian <pgman@candle.pha.pa.us>)
Ответы Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE  (Bruce Momjian <pgman@candle.pha.pa.us>)
Список pgsql-hackers
Bruce Momjian <pgman@candle.pha.pa.us> writes:
> Rod Taylor wrote:
>> Anyway, it shows a situation where it would be nice to differentiate
>> between statement_timeout and lock_timeout OR it demonstrates that I
>> should be using userlocks...

> Wouldn't a LOCK NOWAIT be a better solution?  That is new in 8.0.

LOCK NOWAIT is only helpful if you can express your problem as not
wanting to wait for a table-level lock.  When you're trying to grab a
row-level lock via SELECT FOR UPDATE, there isn't any provision for
NOWAIT.

The notion of a global lock_timeout setting is bogus IMHO, because
every proposed application of it has failed to consider the locks taken
internally by the system.  But that objection wouldn't apply to a SELECT
FOR UPDATE NOWAIT command where the "no wait" behavior only applied to
the row lock being explicitly grabbed.

I thought I remembered someone working on such a thing just recently.
        regards, tom lane


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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE
Следующее
От: Rod Taylor
Дата:
Сообщение: Re: Postresql 8.0 Beta 3 - SELECT ... FOR UPDATE