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

On Sat, Sep 19, 2009 at 4:17 PM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan <zb@cybertec.at> wrote:
>> Boszormenyi Zoltan írta:
>> > 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
>
> I disagree with Tom on this point.  *If* I was trying to implement  a server
> policy, then sure, it should not be done by embedding the timeout in the SQL
> statement.  But I don't think they want this to implement a server policy.
> (And if we do, why would we thump the poor victims that are waiting on the
> lock, rather than the rogue who decided to take a lock and then camp out on
> it?)  The use case for WAIT [N] is not a server policy, but a UI policy.  I
> have two ways to do this task.  The preferred way needs to lock a row, but
> waiting for it may take too long.  So if I can't get the lock within a
> reasonable time, I fall back on a less-preferred but still acceptable way of
> doing the task, one that doesn't need the lock.  If we move to a new server,
> the appropriate value for the time out does not change, because the
> appropriate level is the concern of the UI and the end users, not the
> database server.  This wouldn't be scattered all over the application,
> either.  In my experience, if you have an application that could benefit
> from this, you might have 1 or 2 uses for WAIT [N] out of 1,000+ statements
> in the application.  (From my perspective, if there were to be a WAIT [N]
> option, it could plug into the statement_timeout mechanism rather than the
> proposed lock_timeout mechanism.)
>
> I think that if the use case for a GUC is to set it, run a single very
> specific statement, and then unset it, that is pretty clear evidence that
> this should not be a GUC in the first place.

+1 to all of the above.

...Robert