From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, christoph(dot)berg(at)credativ(dot)de, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error |
Date: | 2022-06-10 16:12:11 |
Message-ID: | 2656555.1654877531@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
I wrote:
> ISTM that an appropriate fix would be to remember if any command
> failed, not just the last one.
Alternatively, one could argue that once we've decided to issue
ROLLBACK, there's not really any reason to continue performing
additional -c/-f actions, so that a sufficient fix would be to
get rid of the loop's ON_ERROR_STOP conditionality:
- if (successResult != EXIT_SUCCESS && pset.on_error_stop)
+ if (successResult != EXIT_SUCCESS)
break;
But I'm not sure that that argument is bulletproof. If we are
considering a client-side failure then the server may still think
the transaction is fine, in which case we should continue to
perform actions that could have client-side side effects; or
at least, not doing so is a potentially significant behavioral
change.
In any case, I now agree with Robert's upthread objection that
this should not have been back-patched. It's a nontrivial
behavioral change and it's not clear that it's 100% without
downsides. I particularly do not want to ship 14.4 with this,
because we really need a clean release with no new regressions.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-06-10 19:45:58 | Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error |
Previous Message | Tom Lane | 2022-06-10 15:41:49 | Re: BUG #17504: psql --single-transaction -vON_ERROR_STOP=1 still commits after client-side error |