On Tue, 2004-06-29 at 18:36, Josh Berkus wrote:
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
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

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

Search Discussions

Discussion Posts


Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 15 of 16 | next ›
Discussion Overview
grouppgsql-hackers @
postedJun 28, '04 at 3:29a
activeJun 30, '04 at 3:19a



site design / logo © 2021 Grokbase