Re: timeout on lock feature
От | Henryk Szal |
---|---|
Тема | Re: timeout on lock feature |
Дата | |
Msg-id | 9bh0q7$136l$1@news.tht.net обсуждение исходный текст |
Ответ на | Re: timeout on lock feature (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Re: timeout on lock feature
|
Список | pgsql-hackers |
Tom Lane wrote in message <4982.987184866@sss.pgh.pa.us>... >Bruce Momjian <pgman@candle.pha.pa.us> writes: >> I was thinking SET because UPDATE does an auto-lock. > >Not to mention a ton of implicit locks acquired on various system tables >during parsing/planning. You really want auto timeout on all of those? >I sure don't. ***************************************** YES, I DO! My transaction can't wait. If parser on planner is blocked, then i want to abort my transaction. ***************************************** > >The appropriate way to do this given a LOCK TABLE option would be like > > BEGIN; > LOCK TABLE foo IN ROW EXCLUSIVE MODE WITH TIMEOUT n; > UPDATE foo SET ...; > COMMIT; > ***************************************** With this solution, some server processes can block me! ***************************************** >which restricts the scope of the timeout behavior to just the specific >lock that the user is thinking of, and doesn't risk breaking fundamental >system operations. > > regards, tom lane ***************************************** This is real problem, but i think other postgres modules are ready for my solution (because it is extension to deadlock detection mechanism) ***************************************** > >---------------------------(end of broadcast)--------------------------- >TIP 6: Have you searched our list archives? > >http://www.postgresql.org/search.mpl
В списке pgsql-hackers по дате отправления: