Re: Error on failed COMMIT

Laurenz Albe <laurenz.albe@cybertec.at>

From: Laurenz Albe <laurenz.albe@cybertec.at>

To: Dave Cramer <davecramer@postgres.rocks>

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-26T17:46:10Z

Lists: pgsql-hackers

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

Yours,
Laurenz Albe