Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
От | Boszormenyi Zoltan |
---|---|
Тема | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Дата | |
Msg-id | 4A6DA653.4050302@cybertec.at обсуждение исходный текст |
Ответ на | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 (Alvaro Herrera <alvherre@commandprompt.com>) |
Список | pgsql-hackers |
Alvaro Herrera írta: > Boszormenyi Zoltan wrote: > >> Alvaro Herrera írta: >> >>> Boszormenyi Zoltan wrote: >>> >>> >>>> The vague consensus for syntax options was that the GUC >>>> 'lock_timeout' and WAIT [N] extension (wherever NOWAIT >>>> is allowed) both should be implemented. >>>> >>>> Behaviour would be that N seconds timeout should be >>>> applied to every lock that the statement would take. >>>> >>> In http://archives.postgresql.org/message-id/291.1242053201@sss.pgh.pa.us >>> Tom argues that lock_timeout should be sufficient. I'm not sure what >>> does WAIT [N] buy. >>> >> Syntax consistency with NOWAIT? >> And easy of use in diverging from default lock_timeout? > Consistency could also be achieved by removing NOWAIT, but I don't see > you proposing that. > And you won't see me proposing any other feature removal either :-) -- Bible has answers for everything. Proof: "But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil." (Matthew 5:37) - basics of digital technology. "May your kingdom come" - superficial description of plate tectonics ---------------------------------- Zoltán Böszörményi Cybertec Schönig & Schönig GmbH http://www.postgresql.at/
В списке pgsql-hackers по дате отправления: