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