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
