logo       

Re: [HACKERS] SELECT ... FOR UPDATE [WAIT integer | NOWAIT] for 8.5: msg#01770

pgsql-hackers

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

Bruce Momjian írta:
> Hans-Juergen Schoenig wrote:
>
>> hello everybody,
>>
>> from my side the goal of this discussion is to extract a consensus so
>> that we can go ahead and implement this issue for 8.5.
>> our customer here needs a solution to this problem and we have to come
>> up with something which can then make it into PostgreSQL core.
>> how shall we proceed with the decision finding process here?
>> i am fine with a GUC and with an grammar extension - i just need a
>> decision which stays unchanged.
>>
>
> Do we have answer for Hans-Juergen here?
>

Do we?

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.

Can we go ahead implementing it?

> I have added a vague TODO:
>
> Consider a lock timeout parameter
>
> * http://archives.postgresql.org/pgsql-hackers/2009-05/msg00485.php
>
>


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


--
Sent via pgsql-hackers mailing list (pgsql-hackers@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | Mail Home | sitemap | FAQ | advertise