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

From ncm@zembu.com (Nathan Myers)
Subject Re: timeout on lock feature
Date
Msg-id 20010418190101.N3797@store.zembu.com
Whole thread Raw
In response to Re: timeout on lock feature  (Bruce Momjian <pgman@candle.pha.pa.us>)
List pgsql-hackers
On Wed, Apr 18, 2001 at 09:39:39PM -0400, Bruce Momjian wrote:
> > 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.

Good: add a timeout feature to psql.  

There's no limit to what features you might add to the database 
core once you decide that new features need have nothing to do with 
databases.  Why not (drum roll...) deliver e-mail?

Nathan Myers
ncm@zembu.com


pgsql-hackers by date:

Previous
From: Tatsuo Ishii
Date:
Subject: Re: Re: No printable 7.1 docs?
Next
From: Tom Lane
Date:
Subject: Re: [BUG] views and functions on relations