Re: Exclusive lock for database rename - Mailing list pgsql-hackers

From Jim C. Nasby
Subject Re: Exclusive lock for database rename
Date
Msg-id 20051108211434.GU19551@pervasive.com
Whole thread Raw
In response to Re: Exclusive lock for database rename  (Martijn van Oosterhout <kleptog@svana.org>)
Responses Re: Exclusive lock for database rename
List pgsql-hackers
On Sat, Nov 05, 2005 at 11:48:56AM +0100, Martijn van Oosterhout wrote:
> On Sat, Nov 05, 2005 at 10:47:30AM +0100, Jochem van Dieten wrote:
> > On 11/4/05, Jim C. Nasby wrote:
> > >
> > > I would argue that in cases like this (and 'this' means just about any
> > > DDL, for starters) that it would be better not to block everyone until
> > > work can actually be done. Or at least make that an option.
> > 
> > Would it be possible to simulate this by manually trying to grab a
> > lock on a relation using NOWAIT in a loop or are the locks DDL
> > requires different from the ones acquired by the LOCK statement?
> 
> What you want is probably some kind of "attempt to grab lock with
> timeout". Ie, it tries to grab the lock but gets stuck waiting for
> someone else. After some timeout it fails, waits a few seconds and
> tries again. That few seconds allows other clients waiting for you to
> unstuck.
> 
> Set the timeout to maybe 30 seconds. Then no query will wait for your
> lock for more than 30 seconds. Or maybe exponentially rising delay,
> otherwise you'll never guarentee completion. With notice to client what
> is happening, hopefully...

BTW, if you come up with a working example of this it would be a great
addition to the docs.
-- 
Jim C. Nasby, Sr. Engineering Consultant      jnasby@pervasive.com
Pervasive Software      http://pervasive.com    work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf       cell: 512-569-9461


pgsql-hackers by date:

Previous
From: Michael Paesold
Date:
Subject: Re: Interval aggregate regression failure (expected seems
Next
From: Tom Lane
Date:
Subject: Re: lc_numeric and decimal delimiter