Re: PSQL undesired transaction behavior when connection is lost.

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Steven Klassen <sklassen(at)commandprompt(dot)com>
Cc: Mike Benoit <ipso(at)snappymail(dot)ca>, pgsql-general(at)postgresql(dot)org, Peter Eisentraut <peter_e(at)gmx(dot)net>
Subject: Re: PSQL undesired transaction behavior when connection is lost.
Date: 2004-10-07 20:33:26
Message-ID: 23483.1097181206@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Steven Klassen <sklassen(at)commandprompt(dot)com> writes:
> * Mike Benoit <ipso(at)snappymail(dot)ca> [2004-10-07 11:47:50 -0700]:
>> I assume I'm not the first person to run in to this, however
>> searching google didn't seem to come up with anything useful.

> AFAICT, the first query is just constructed poorly, while the second
> seems to recurse on itself. The order in the sub-selects doesn't seen
> necessary either.

Agreed, but I think that's irrelevant to his point: psql probably
should abandon whatever is left in its input buffer after getting an
error from the backend, and almost certainly should do so after loss
of connection. In the noninteractive case I believe it will quit
executing the script file, which is good, but in the interactive case
it seems like a mistake not to flush the query buffer.

Peter, do you know if this behavior was intentional, or just an
implementation artifact?

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Steven Klassen 2004-10-07 20:39:31 Re: PSQL undesired transaction behavior when connection is lost.
Previous Message Martijn van Oosterhout 2004-10-07 20:22:24 Question about timezones