| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>, Christoph Berg <christoph(dot)berg(at)credativ(dot)de>, PostgreSQL mailing lists <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-07 02:53:08 |
| Message-ID: | Yp69lO4sAtP3xUZJ@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
On Mon, Jun 06, 2022 at 01:05:46PM -0700, David G. Johnston wrote:
> We've done worse when dealing with obvious bugs contrary to the
> documentation and that prevent unsafe behavior. People relying on the
> defined behavior to safely fail when encountering unexpected failure
> producing situations that hopefully never happen get the priority over
> poorly written code that somehow relies on errors not respecting the single
> transaction promise.
Yeah, I think that the past behavior was a bit crazy. On a
client-side error, psql reports a failure with an error code but would
commit any changes that happened before the command that failed with
the underlying commit created by --single-transaction, while
discarding any future commands.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David Rowley | 2022-06-07 03:17:15 | Re: BUG #17512: Process running query fails with SIGSEV - nodeMemoize.c:349 |
| Previous Message | hirose.masay-01@fujitsu.com | 2022-06-07 01:14:50 | RE: BUG #17421: Core dump in ECPGdo() when calling PostgreSQL API from 32-bit client for RHEL8 |