Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Дата
Msg-id 7068.1242064894@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Boszormenyi Zoltan <zb@cybertec.at>)
Ответы Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Boszormenyi Zoltan <zb@cybertec.at>)
Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Josh Berkus <josh@agliodbs.com>)
Список pgsql-hackers
Boszormenyi Zoltan <zb@cybertec.at> writes:
> Tom Lane �rta:
>> I think the way you're describing would be both harder to implement
>> and full of its own strange traps.

> Why?

Well, for one thing: if I roll back a subtransaction, should the lock
wait time it used now no longer count against the total?  If not,
once a timeout failure has occurred it'll no longer be possible for
the total transaction to do anything, even if it rolls back a failed
subtransaction.

But more generally, what you are proposing seems largely duplicative
with statement_timeout.  The only reason I can see for a
lock-wait-specific timeout is that you have a need to control the
length of a specific wait and *not* the overall time spent.  Hans
already argued upthread why he wants a feature that doesn't act like
statement_timeout.
        regards, tom lane


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

Предыдущее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Следующее
От: Boszormenyi Zoltan
Дата:
Сообщение: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5