Re: Error on failed COMMIT
От | Haumacher, Bernhard |
---|---|
Тема | Re: Error on failed COMMIT |
Дата | |
Msg-id | b5fcab28-f1dc-65c8-687a-7eed5522e96c@haumacher.de обсуждение исходный текст |
Ответ на | Re: Error on failed COMMIT (David Fetter <david@fetter.org>) |
Список | 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
В списке pgsql-hackers по дате отправления: