Re: Lock!
От | Ang Chin Han |
---|---|
Тема | Re: Lock! |
Дата | |
Msg-id | 3F8CCC7F.6@bytecraft.com.my обсуждение исходный текст |
Ответ на | Re: Lock! (Oliver Elphick <olly@lfix.co.uk>) |
Ответы |
Locks
Re: Lock! |
Список | pgsql-admin |
Oliver Elphick wrote: > You can't. > > Quote from the manual: > So long as no deadlock situation is detected, a transaction > seeking either a table-level or row-level lock will wait > indefinitely for conflicting locks to be released. This means it > is a bad idea for applications to hold transactions open for > long periods of time (e.g., while waiting for user input). Unless you set STATEMENT_TIMEOUT: http://www.postgresql.org/docs/7.3/static/runtime-config.html#RUNTIME-CONFIG-GENERAL In other words, try: SET STATEMENT_TIMEOUT=50; SELECT * FROM foo WHERE foo_id = 1 FOR UPDATE; That means if another process is locking foo_id = 1 row for more than 50 millisecond after you try to SELECT it FOR UPDATE, you'll get an error/rollback, and you can then assume it's being used. Just remember to reset STATEMENT_TIMEOUT to zero or your default before any slow queries in that transaction. There was some discussion about emulating (IIRC) Oracle's SELECT .. FOR UPDATE NOWAIT somewhere in the Postgresql archives. Look them up for more details.
Вложения
В списке pgsql-admin по дате отправления: