| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
| Cc: | Thomas Lockhart <lockhart(at)fourpalms(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jessica Perry Hekman <jphekman(at)dynamicdiagrams(dot)com>, Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>, Jan Wieck <janwieck(at)yahoo(dot)com>, Barry Lind <barry(at)xythos(dot)com>, <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: timeout implementation issues |
| Date: | 2002-04-08 16:28:18 |
| Message-ID: | Pine.LNX.4.30.0204081224560.685-100000@peter.localdomain |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| 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(at)gmx(dot)net
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hiroshi Inoue | 2002-04-08 16:32:52 | Re: timeout implementation issues |
| Previous Message | Bruce Momjian | 2002-04-08 16:27:32 | Re: timeout implementation issues |