From: | Tony Locke <tlocke(at)tlocke(dot)org(dot)uk> |
---|---|
To: | Shay Rojansky <roji(at)roji(dot)org> |
Cc: | Dave Cramer <davecramer(at)postgres(dot)rocks>, Bruce Momjian <bruce(at)momjian(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Vik Fearing <vik(at)postgresfriends(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Vladimir Sitnikov <sitnikov(dot)vladimir(at)gmail(dot)com>, "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-04-18 15:27:55 |
Message-ID: | CAPpF0yN5VmOPwp8yFgR0PH3n_BsoSTcHkhjZ1ox1QbYM_1uXtQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 16 Apr 2020 at 21:16, Shay Rojansky <roji(at)roji(dot)org> wrote:
> Npgsql would be fine. In fact, Npgsql doesn't have any specific expectations nor any specific logic around commit; it assumes errors may be returned for any command (COMMIT or otherwise), and surfaces those errors as .NET exceptions.
Hi all, I work on the pg8000 Python driver for Postgres and having
read through the thread I'd like to echo Shay Rojansky's comment and
say that pg8000 would be able to handle the behaviour resulting from
the proposed patch and I support the change of a call to commit()
*always* producing an error if it has failed. I can understand
people's reluctance in general to change server behaviour, but in this
case I think the good outweighs the bad. I think most people expected
the server to be behaving like this anyway.
Regards,
Tony.
From | Date | Subject | |
---|---|---|---|
Next Message | Julien Rouhaud | 2020-04-18 15:39:35 | Re: WAL usage calculation patch |
Previous Message | Robert Haas | 2020-04-18 15:04:48 | Re: where should I stick that backup? |