Horton

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

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
Cc: christoph.berg@credativ.de, pgsql-bugs@lists.postgresql.org
Date: 2022-06-06T02:15:44Z
Lists: pgsql-bugs 
On Fri, Jun 03, 2022 at 05:56:03PM +0900, Kyotaro Horiguchi wrote:
> At Thu, 2 Jun 2022 14:39:41 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
>> 001_basic.pl, but we also need to be careful when sending down queries
>> with psql expected to fail because of SIGPIPE (c757a3d, 6d41dd0).  The
> 
> This does not need to send a byte after the client-side failure. The
> connection is rather living after failure in this case.

Sure, but I don't think that we can reliably test the case where one
of the switches triggers a backend-side error, which is what my point
is about.  I have added a note about that, with a couple of extra
tests with -f, with both success and failure scenarios.  And we'd
better add -X to all the commands as well.  These are added only on
HEAD as the test file is rather new.

>> 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.
--
Michael

Commits

  1. Tweak behavior of psql --single-transaction depending on ON_ERROR_STOP

  2. Doc: remove a04ccf6df from release notes, now that it's reverted.

  3. Revert "Fix psql's single transaction mode on client-side errors with -c/-f switches".

  4. Fix psql's single transaction mode on client-side errors with -c/-f switches