Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
От | Boszormenyi Zoltan |
---|---|
Тема | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 |
Дата | |
Msg-id | 4A088C7E.4000803@cybertec.at обсуждение исходный текст |
Ответ на | Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 (Josh Berkus <josh@agliodbs.com>) |
Список | pgsql-hackers |
Josh Berkus írta: > >> 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. > > I agree with Tom here; I want to wait for a specific amount of time > for a specific lock request. > Well, thinking about it a bit more, I think we can live with that. The use case would be mostly 1 record per SELECT FOR UPDATE WAIT N query, so for this the two semantics are equal. We would differ from Informix when one SELECT fetches more than one record obviously. We can have both GUC and the SQL extension for temporary setting. SET lock_timeout = N; -- 0 means infinite? or: SET lock_timeout = infinite; NOWAIT | WAIT (or no keyword as of now) for infinite waiting | WAIT DEFAULT | WAIT N (N seconds timeout) Comments? -- 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 по дате отправления: