On Sat, Sep 19, 2009 at 4:17 PM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Sep 3, 2009 at 6:47 AM, Boszormenyi Zoltan <z...@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.1242053...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
