Horton

Re: timeout implementation issues

Karel Zak <zakkr@zf.jcu.cz>

View thread
From: Karel Zak <zakkr@zf.jcu.cz>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Bruce Momjian <pgman@candle.pha.pa.us>, 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-09T07:54:56Z
Lists: pgsql-hackers 
On Mon, Apr 08, 2002 at 12:28:18PM -0400, Peter Eisentraut wrote:
> 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;

 If I compare Peter's and Bruce's examples the Peter is still winner :-)

 Sorry, but a code with "set-it-after-abort" seems ugly.

        Karel

-- 
 Karel Zak  <zakkr@zf.jcu.cz>
 http://home.zf.jcu.cz/~zakkr/
 
 C, PostgreSQL, PHP, WWW, http://docs.linux.cz, http://mape.jcu.cz