Re: Error on failed COMMIT
От | Dave Cramer |
---|---|
Тема | Re: Error on failed COMMIT |
Дата | |
Msg-id | CADK3HHLddDxgNZz+HJHJ3n6ZAYLjpsP5W6KF2msH-iZAXouXQg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Error on failed COMMIT (Laurenz Albe <laurenz.albe@cybertec.at>) |
Ответы |
Re: Error on failed COMMIT
|
Список | pgsql-hackers |
On Tue, 26 Jan 2021 at 12:46, Laurenz Albe <laurenz.albe@cybertec.at> wrote:
On Tue, 2021-01-26 at 12:25 -0500, Dave Cramer wrote:
> > After thinking some more about it, I think that COMMIT AND CHAIN would have
> > to change behavior: if COMMIT throws an error (because the transaction was
> > aborted), no new transaction should be started. Everything else seems fishy:
> > the statement fails, but still starts a new transaction?
> >
> > I guess that's also at fault for the unexpected result status that
> > Masahiko complained about in the other message.
>
>
> I haven't had a look at the result status in libpq. For JDBC we don't see that.
> We throw an exception when we get this error report. This is very consistent as the commit fails and we throw an exception
>
> > So I think we should not introduce USER_ERROR at all. It is too much
> > of a kluge: fail, but not really...
>
> What we do now is actually worse as we do not get an error report and we silently change commit to rollback.
> How is this better ?
I see your point from the view of the JDBC driver.
It just feels hacky - somewhat similar to what you say
above: don't go through the normal transaction rollback steps,
but issue an error message.
At least we should fake it well...
OK, let me look into how we deal with COMMIT and CHAIN.
I can see some real issues with this as Vik pointed out.
Dave
В списке pgsql-hackers по дате отправления: