Re: timeout implementation issues

Bruce Momjian <pgman@candle.pha.pa.us>

From: Bruce Momjian <pgman@candle.pha.pa.us>
To: Jessica Perry Hekman <jphekman@dynamicdiagrams.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Jan Wieck <janwieck@yahoo.com>, pgsql-hackers@postgresql.org
Date: 2002-04-02T18:39:30Z
Lists: pgsql-hackers
Jessica Perry Hekman wrote:
> On Mon, 1 Apr 2002, Tom Lane wrote:
> 
> > On the other hand, we do not have anything in the backend now that
> > applies to just one statement and then automatically resets afterwards;
> > and I'm not eager to add a parameter with that behavior just for JDBC's
> > convenience.  It seems like it'd be a big wart.
> 
> Does that leave us with implementing query timeouts in JDBC (timer in the
> driver; then the driver sends a cancel request to the backend)?

No, I think we have to find a way to do this in the backend; just not
sure how yet.

I see the problem Tom is pointing out, that SET is ignored if the
transaction has already aborted:
	
	test=> begin;
	BEGIN
	test=> lkjasdf;
	ERROR:  parser: parse error at or near "lkjasdf"
	test=> set server_min_messages = 'log';
	WARNING:  current transaction is aborted, queries ignored until end of
	transaction block
	*ABORT STATE*
	test=> 

so if the transaction aborted, the reset of the statement_timeout would
not happen.  The only way the application could code this would be with
this:

	BEGIN WORK;
	query;
	SET statement_timeout = 4;
	query;
	SET statement_timeout = 0;
	query;
	COMMIT;
	SET statement_timeout = 0;

Basically, it does the reset twice, once assuming the transaction
doesn't abort, and another assuming it does abort.  Is this something
that the JDBC and ODBC drivers can do automatically?

-- 
  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, Pennsylvania 19026