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

From Kyotaro Horiguchi
Subject Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error
Date
Msg-id 20220531.113927.640026319524742851.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error  (Christoph Berg <christoph.berg@credativ.de>)
Responses Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error
List pgsql-bugs
At Mon, 30 May 2022 17:18:28 +0200, Christoph Berg <christoph.berg@credativ.de> wrote in 
> Re: PG Bug reporting form
> > The problem is not limited to \copy; \i has the same problem.
> > A workaround is to drop -1, and use an explicit transaction in the script.
> 
> \connect correctly aborts the whole operation.
> 
> I would suggest that all client-side errors should be handled as fatal
> when both --single-transaction and -vON_ERROR_STOP=1 are in effect.

The code looks like just a thinko that "COMMIT" works fine even if the
given commands have ended in failure. But actually it doesn't for
client-side failure.

diff --git a/src/bin/psql/startup.c b/src/bin/psql/startup.c
index ddff903915..2261f78f81 100644
--- a/src/bin/psql/startup.c
+++ b/src/bin/psql/startup.c
@@ -426,7 +426,9 @@ main(int argc, char *argv[])
 
                if (options.single_txn)
                {
-                       if ((res = PSQLexec("COMMIT")) == NULL)
+                       res = PSQLexec(successResult == EXIT_SUCCESS ?
+                                                  "COMMIT" : "ROLLBACK");
+                       if (res == NULL)
                        {
                                if (pset.on_error_stop)
                                {

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-bugs by date:

Previous
From: Michael Paquier
Date:
Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY
Next
From: Michael Paquier
Date:
Subject: Re: BUG #17485: Records missing from Primary Key index when doing REINDEX INDEX CONCURRENTLY