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
Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Список | 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 по дате отправления: