Horton

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

Kyotaro Horiguchi <horikyota.ntt@gmail.com>

View thread View on postgr.es
From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: michael@paquier.xyz
Cc: christoph.berg@credativ.de, pgsql-bugs@lists.postgresql.org
Date: 2022-06-03T08:56:03Z
Lists: pgsql-bugs

Attachments

Thanks for the suggestions!

At Thu, 2 Jun 2022 14:39:41 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> The change that you are sending would enforce this policy as Christoph
> would like.  Some tests would be nice to check such behaviors, say in

Added a test.

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

> docs need a refresh, they mention now that COMMIT is sent after the
> last command but that would not be the case anymore with this patch if
> there is a client-side error.

Agreed. Does the following work?

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

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

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