Re: Error on failed COMMIT

Haumacher, Bernhard <haui@haumacher.de>

From: "Haumacher, Bernhard" <haui@haumacher.de>
To: David Fetter <david@fetter.org>, Vik Fearing <vik@postgresfriends.org>
Cc: Robert Haas <robertmhaas@gmail.com>, Shay Rojansky <roji@roji.org>, Dave Cramer <davecramer@postgres.rocks>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2020-02-26T18:33:56Z
Lists: pgsql-hackers
Am 24.02.2020 um 13:34 schrieb Robert Haas:
> As I said upthread, I think one of the things that would be pretty
> badly broken by this is psql -f something.sql, where something.sql
> contains a series of blocks of the form "begin; something; something;
> something; commit;". Right now whichever transactions succeed get
> committed. With the proposed change, if one transaction block fails,
> it'll merge with all of the following blocks.


No, that's *not* true.

The only difference with the proposed change would be another error in 
the logs for the commit following the block with the failed insert. 
Note: Nobody has suggested that the commit that returns with an error 
should not end the transaction. Do just the same as with any other 
commit error in response to a constraint violation!


Am 24.02.2020 um 18:53 schrieb David Fetter:
> On Mon, Feb 24, 2020 at 06:40:16PM +0100, Vik Fearing wrote:
>> On 24/02/2020 18:37, David Fetter wrote:
>>> If we'd done this from a clean sheet of paper, it would have been the
>>> right decision. We're not there, and haven't been for decades.
>> OTOH, it's never too late to do the right thing.
> Some right things take a lot of prep work in order to actually be
> right things. This is one of them.  Defaulting to SERIALIZABLE
> isolation is another.


Here the proposed changes is really much much less noticable - please 
report the error (again) instead of giving an incomprehensible status 
code. Nothing else must be changed - the failing commit should do the 
rollback and end the transaction - but it should report this situation 
as an error!

Regards Bernhard