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: I have an OLAP database of regional office evaluations (in SQL Server, sadly) 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 SQL Server's lock timeout functionality for this; bascially, the data entry waits for 30 seconds, and then tells the user to try again in 10 minutes. I could do the same thing in PostgreSQL using NOWAIT and a loop on the client side. But the lock timeout is somewhat easier. -- Josh Berkus Aglio Database Solutions San Francisco ---------------------------(end of broadcast)--------------------------- TIP 4: Don't 'kill -9' the postmaster
