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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Следующее
От: Tom Lane
Дата:
Сообщение: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5