Re: timeout on lock feature - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: timeout on lock feature
Date
Msg-id 200104190139.f3J1ddO10137@candle.pha.pa.us
Whole thread Raw
In response to Re: timeout on lock feature  (ncm@zembu.com (Nathan Myers))
Responses Re: timeout on lock feature  (ncm@zembu.com (Nathan Myers))
List pgsql-hackers
> On Wed, Apr 18, 2001 at 07:33:24PM -0400, Bruce Momjian wrote:
> > > What might be a reasonable alternative would be a BEGIN timeout: report 
> > > failure as soon as possible after N seconds unless the timer is reset, 
> > > such as by a commit.  Such a timeout would be meaningful at the 
> > > database-interface level.  It could serve as a useful building block 
> > > for application-level timeouts when the client environment has trouble 
> > > applying timeouts on its own.
> > 
> > Now that is a nifty idea.  Just put it on one command, BEGIN, and have
> > it apply for the whole transaction.  We could just set an alarm and do a
> > longjump out on timeout.
> 
> Of course, it begs the question why the client couldn't do that
> itself, and leave PG out of the picture.  But that's what we've 
> been talking about all along.

Yes, they can, but of course, they could code the database in the
application too.  It is much easier to put the timeout in a psql script
than to try and code it.

--  Bruce Momjian                        |  http://candle.pha.pa.us pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026
 


pgsql-hackers by date:

Previous
From: Alex Pilosov
Date:
Subject: Re: [BUG] views and functions on relations
Next
From: Tatsuo Ishii
Date:
Subject: Re: Re: [PATCHES] Fix for psql core dumping on bad user