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 ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly