| From: | Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | Vik Fearing <vik(at)postgresfriends(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Dave Cramer <davecramer(at)gmail(dot)com> |
| Subject: | Re: Error on failed COMMIT |
| Date: | 2020-02-25 08:42:47 |
| Message-ID: | CAB=Je-GqPtOG-W6A8gkDHb5swQK8YZ+JLzAZbi_5v=JE4UD2hw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Tom>I think we still end up concluding that altering this behavior has more
Tom>downside than upside.
What is the downside?
Applications, drivers, and poolers already expect that commit might produce
an error and terminate the transaction at the same time.
"The data is successfully committed to the database if and only if commit
returns without error".
^^^ the above is way easier to reason about than "user must check multiple
unrelated outcomes to tell if the changes are committed or not".
Vladimir
| From | Date | Subject | |
|---|---|---|---|
| Next Message | 曾文旌 (义从) | 2020-02-25 08:53:21 | Re: [Proposal] Global temporary tables |
| Previous Message | Amit Langote | 2020-02-25 08:42:22 | Re: plan cache overhead on plpgsql expression |