Skip site navigation (1) Skip section navigation (2)

Re: lock timeout patch

From: Josh Berkus <josh(at)agliodbs(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: lock timeout patch
Date: 2004-06-29 17:36:48
Message-ID: 200406291036.48477.josh@agliodbs.com (view raw or flat)
Thread:
Lists: pgsql-adminpgsql-hackers
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

Responses

pgsql-hackers by date

Next:From: Darko PrenosilDate: 2004-06-29 17:37:57
Subject: Re: User Privileges using dblink
Previous:From: Darko PrenosilDate: 2004-06-29 17:17:01
Subject: Re: INSERT rule

pgsql-admin by date

Next:From: Lee WuDate: 2004-06-29 18:49:11
Subject: Re: Stopping vacuum
Previous:From: CHRIS HOOVERDate: 2004-06-29 17:30:00
Subject: Re: Stopping vacuum

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group