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

Tom Lane írta:
> Boszormenyi Zoltan <zb(at)cybertec(dot)at> writes:
>
>> Tom Lane írta:
>>
>>> I think the way you're describing would be both harder to implement
>>> and full of its own strange traps.
>>>
>
>
>> Why?
>>
>
> Well, for one thing: if I roll back a subtransaction, should the lock
> wait time it used now no longer count against the total?

Does statement_timeout counts against subtransactions as well? No.
If a statement finishes before statement_timeout, does it also decrease
the possible runtime for the next statement? No. I was talking about
locks acquired during one statement.

> If not,
> once a timeout failure has occurred it'll no longer be possible for
> the total transaction to do anything, even if it rolls back a failed
> subtransaction.
>
> 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.
>

He argued about he wants a timeout *independent* from statement_timeout
for locks only inside the same statement IIRC.

> regards, tom lane
>
>

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