Re: timeout on lock feature

From: ncm(at)zembu(dot)com (Nathan Myers)
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: timeout on lock feature
Date: 2001-04-19 02:01:01
Message-ID: 20010418190101.N3797@store.zembu.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)zembu(dot)com

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2001-04-19 02:02:06 Re: [BUG] views and functions on relations
Previous Message Tom Lane 2001-04-19 01:44:08 Re: [BUG] views and functions on relations