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