Re: SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5

Boszormenyi Zoltan <zb@cybertec.at>

From: Boszormenyi Zoltan <zb@cybertec.at>
To: pgsql-hackers@postgresql.org
Cc: Alvaro Herrera <alvherre@commandprompt.com>, Bruce Momjian <bruce@momjian.us>, Hans-Juergen Schoenig <postgres@cybertec.at>, Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>, Sándor Miglécz <sandor@cybertec.at>
Date: 2009-07-30T12:47:31Z
Lists: pgsql-hackers

Attachments

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

Okay, we implemented only the lock_timeout GUC.
Patch attached, hopefully in an acceptable form.
Documentation included in the patch, lock_timeout
works the same way as statement_timeout, takes
value in milliseconds and 0 disables the timeout.

Best regards,
Zoltán Böszörményi

-- 
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/