On Tue, 2004-06-29 at 18:36, Josh Berkus wrote:
> Tom,
>
> > I'd accept a mechanism to enforce a timeout at the lock level if you
> > could show me a convincing use-case for lock timeouts instead of
> > statement timeouts, but I don't believe there is one. I think this
> > proposal is a solution in search of a problem.
>
> Hmmm ... didn't we argue this out with NOWAIT? What did we conclude then?
> I'm reluctant to go over old ground repeatedly.
>
> Let me say for myself that I would use this feature if it existed, but would
> not miss it a whole lot if the patch was rejected. Here's the idea:
>
Can't vouch for the patch, but I can say this would get used...
> I have an ... database ...
> which requires that the evaluations, sometimes interlocking, of regions be
> "closed" simultaneously (in one transaction). This means that during the
> closure process, certain kinds of data entry needs to be frozen out. I am
> using ... lock timeout functionality for this; bascially, the data
> entry waits for 30 seconds, and then tells the user to try again in 10
> minutes.
Just implementing this same scenario, using DB2 (...). Of course, if I
had MVCC on that application, I could argue that this is not
required...is that the basis of the "not required" view?
>
> I could do the same thing in PostgreSQL using NOWAIT and a loop on the client
> side. But the lock timeout is somewhat easier.
SQLServer and DB2 support a lock timeout system wide, simple but not
granular. Oracle supports the NOWAIT option, even though it supports
readers-dont-block locking. I prefer the NOWAIT option as it gives a
more detailed handle on the exact statements that you wish to wait, or
not.
Without NOWAIT, we would need to set lock_timeout = 30 (seconds)
Statement level timeout is a different thing entirely, since there are
very often statements that need to run for 2-3 hours (even more in some
cases), so statement level timeout is set to 10000 (seconds).
Best Regards, Simon Riggs