Re: Error on failed COMMIT - Mailing list pgsql-hackers

From Vladimir Sitnikov
Subject Re: Error on failed COMMIT
Date
Msg-id CAB=Je-Ger+TZHLHhphQx3H8K0+Xi1jagT06oMuhD1=v7zn4fmw@mail.gmail.com
Whole thread Raw
In response to Re: Error on failed COMMIT  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: Error on failed COMMIT
List pgsql-hackers
Merlin>My biggest sense of alarm with the proposed change is that it could
Merlin>leave applications in a state where the transaction is hanging there

How come?
The spec says commit ends the transaction.
Can you please clarify where the proposed change leaves a hanging transaction?

Just in case, the proposed change is as follows:

postgres=# begin;
BEGIN
postgres=# aslkdfasdf;
ERROR:  syntax error at or near "aslkdfasdf"
LINE 1: aslkdfasdf;
        ^
postgres=# commit;
ROLLBACK   <-- this should be replaced with "ERROR: can't commit the transaction because ..."
postgres=# commit;
WARNING:  there is no transaction in progress  <-- this should be as it is currently. Even if commit throws an error, the transaction should be terminated.
COMMIT

No-one on the thread suggests the transaction must hang forever.
Of course, commit must terminate the transaction one way or another.
The proposed change is to surface the exception if user tries to commit or prepare a transaction that can't be committed.
Note: the reason does not matter much. If deferred constraint fails on commit, then commit itself throws an error.
Making commit throw an error in case "current transaction is aborted" makes perfect sense.

Note: the same thing is with PREPARE TRANSACTION 'txname`.
Apparently it silently responses with ROLLBACK which is strange as well.

Vladimir

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgsql: Add kqueue(2) support to the WaitEventSet API.
Next
From: Vik Fearing
Date:
Subject: Re: Error on failed COMMIT