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