Re: timeout implementation issues

Peter Eisentraut <peter_e@gmx.net>

From: Peter Eisentraut <peter_e@gmx.net>

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

Cc: Thomas Lockhart <lockhart@fourpalms.org>, Tom Lane <tgl@sss.pgh.pa.us>, Jessica Perry Hekman <jphekman@dynamicdiagrams.com>, Hiroshi Inoue <Inoue@tpf.co.jp>, Jan Wieck <janwieck@yahoo.com>, Barry Lind <barry@xythos.com>, <pgsql-hackers@postgresql.org>

Date: 2002-04-08T16:28:18Z

Lists: pgsql-hackers

Bruce Momjian writes:

> OK, probably good time for summarization.  First, consider this:
>
> 	BEGIN WORK;
> 	SET something;
> 	query fails;
> 	SET something else;
> 	COMMIT WORK;
>
> Under current behavior, the first SET is honored, while the second is
> ignored because the transaction is in ABORT state.  I can see no logical
> reason for this behavior.

But that is not a shortcoming of the SET command.  The problem is that the
system does not accept any commands after one command has failed in a
transaction even though it could usefully do so.

> The jdbc timeout issue is this:
>
>
> 	BEGIN WORK;
> 	SET query_timeout=20;
> 	query fails;
> 	SET query_timeout=0;
> 	COMMIT WORK;
>
> In this case, with our current code, the first SET is done, but the
> second is ignored.

Given appropriate functionality, you could rewrite this thus:

BEGIN WORK;
SET FOR THIS TRANSACTION ONLY query_timeout=20;
query;
COMMIT WORK;

-- 
Peter Eisentraut   peter_e@gmx.net