Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error - Mailing list pgsql-bugs

From Tom Lane
Subject Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error
Date
Msg-id 2649417.1654875709@sss.pgh.pa.us
Whole thread Raw
In response to Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error  (Michael Paquier <michael@paquier.xyz>)
Responses Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
Michael Paquier <michael@paquier.xyz> writes:
> On Fri, Jun 03, 2022 at 05:56:03PM +0900, Kyotaro Horiguchi wrote:
>>> It causes psql to issue a BEGIN command before the first such option
>>> and a COMMIT command after the last one, thereby wrapping all the
>>> commands into a single transaction.
>>> If any of the commands fails, a ROLLBACK command is sent instead.
>>> This ensures that either all the commands complete successfully, or
>>> no changes are applied.

> Looks fine to me, so applied down to 10.

While preparing release notes, I had to study this commit to figure
out what it actually did, and I do not think it is right yet.  It
definitely does not do what is claimed above, ie rollback if "any"
of the steps fails.  As coded, it rolls back only if the *last*
step fails.  Now, if you've got ON_ERROR_STOP set, then the loop
terminates after an error so there's no difference ... but if you
do not, I think this behavior is not what's expected.

ISTM that an appropriate fix would be to remember if any command
failed, not just the last one.

            regards, tom lane



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17515: Change in behaviour of a composite type within a domain
Next
From: Tom Lane
Date:
Subject: Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error