Re: timeout implementation issues - Mailing list pgsql-hackers

From Bruce Momjian
Subject Re: timeout implementation issues
Date
Msg-id 200204011818.g31IIdd06139@candle.pha.pa.us
Whole thread Raw
In response to Re: timeout implementation issues  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: timeout implementation issues, lock timeouts  (Robert Schrem <robert.schrem@WiredMinds.de>)
List pgsql-hackers
Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > ... It will be tricky to manage multiple
> > alarms in a single process, but it can be done by creating an alarm
> > queue.
> 
> I would argue that we should only support *one* kind of timeout, either
> transaction-level or statement-level, so as to avoid that complexity.
> I don't want to see us gilding the lily in the first implementation of
> something that IMHO is of dubious usefulness in the first place.
> We can think about extending the facility later, when and if it proves
> sufficiently useful to justify more complexity.
> 
> I don't have a very strong feeling about whether transaction-level or
> statement-level is more useful; am willing to do whichever one the
> JDBC spec wants.

Agreed, only one timeout.  I just considered the statement/transaction
level quite interesting.  We could easily do GUC for query level, and
allow BEGIN WORK to override that for transaction level.  That would
give us the best of both worlds, if we want it.  I am not sure what
people are going to use this timeout for.  My guess is that only
transaction level is the way to go.

--  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: Bruce Momjian
Date:
Subject: Re: timeout implementation issues
Next
From: Stephan Szabo
Date:
Subject: Re: RI triggers and schemas