Re: Error on failed COMMIT

From: Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Dave Cramer <davecramer(at)postgres(dot)rocks>, Shay Rojansky <roji(at)roji(dot)org>, "Haumacher, Bernhard" <haui(at)haumacher(dot)de>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Error on failed COMMIT
Date: 2020-02-25 07:17:40
Message-ID: CAB=Je-HV4Pm8Wt_KuLyEEOVMNsGX3UEY5zH-S1c9jd7CKx8pgA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert>Now, of course, it's also true that if what the server does makes
Robert>users sad, maybe the server should do something different

The server makes users sad as it reports the same end result (=="commit
failed") differently.
Sometimes the server produces ERROR, and sometimes the server produces "OK,
the transaction was rolled back".

The users do expect that commit might fail, and they don't really expect
that sometimes commit can be silently converted to a rollback.

Robert>BEGIN;
Robert>-- do stuff
Robert>COMMIT;
Robert>BEGIN;
Robert>-- do more stuff
Robert>COMMIT;

Robert>...and they run these scripts by piping them into psql. Now, if the
Robert>COMMIT leaves the session in a transaction state,

Noone suggested that "commit leaves the session in a transaction state".
Of course, every commit should terminate the transaction.
However, if a commit fails (for any reason), it should produce the relevant
ERROR that explains what went wrong rather than silently doing a rollback.

Vladimir

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Antonin Houska 2020-02-25 07:30:57 RS_EPHEMERAL vs RS_TEMPORARY
Previous Message Pavel Stehule 2020-02-25 07:16:09 Re: plan cache overhead on plpgsql expression