Re: Error on failed COMMIT
Dave Cramer <davecramer@postgres.rocks>
From: Dave Cramer <davecramer@postgres.rocks>
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: Andrew Dunstan <andrew.dunstan@2ndquadrant.com>,
Tony Locke <tlocke@tlocke.org.uk>, Shay Rojansky <roji@roji.org>, Bruce Momjian <bruce@momjian.us>,
Robert Haas <robertmhaas@gmail.com>, Vik Fearing <vik@postgresfriends.org>, Tom Lane <tgl@sss.pgh.pa.us>, Vladimir Sitnikov <sitnikov.vladimir@gmail.com>, "Haumacher,
Bernhard" <haui@haumacher.de>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-26T18:02:06Z
Lists: pgsql-hackers
On Tue, 26 Jan 2021 at 12:46, Laurenz Albe <laurenz.albe@cybertec.at> wrote: > On Tue, 2021-01-26 at 12:25 -0500, Dave Cramer wrote: > > > After thinking some more about it, I think that COMMIT AND CHAIN would > have > > > to change behavior: if COMMIT throws an error (because the transaction > was > > > aborted), no new transaction should be started. Everything else seems > fishy: > > > the statement fails, but still starts a new transaction? > > > > > > I guess that's also at fault for the unexpected result status that > > > Masahiko complained about in the other message. > > > > > > I haven't had a look at the result status in libpq. For JDBC we don't > see that. > > We throw an exception when we get this error report. This is very > consistent as the commit fails and we throw an exception > > > > > So I think we should not introduce USER_ERROR at all. It is too much > > > of a kluge: fail, but not really... > > > > What we do now is actually worse as we do not get an error report and we > silently change commit to rollback. > > How is this better ? > > I see your point from the view of the JDBC driver. > > It just feels hacky - somewhat similar to what you say > above: don't go through the normal transaction rollback steps, > but issue an error message. > > At least we should fake it well... > OK, let me look into how we deal with COMMIT and CHAIN. I can see some real issues with this as Vik pointed out. Dave