Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5 - Mailing list pgsql-hackers

From Boszormenyi Zoltan
Subject Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Date
Msg-id 4A088C7E.4000803@cybertec.at
Whole thread Raw
In response to Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Josh Berkus
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5
Next
From: Tom Lane
Date:
Subject: Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5