Re: Error on failed COMMIT

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.

In response to

Responses

Browse pgsql-hackers by date

  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?