|From:||Vik Fearing <vik(at)postgresfriends(dot)org>|
|To:||PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>|
|Cc:||Dave Cramer <davecramer(at)gmail(dot)com>|
|Subject:||Error on failed COMMIT|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
There is a current discussion off-list about what should happen when a
COMMIT is issued for a transaction that cannot be committed for whatever
reason. PostgreSQL returns ROLLBACK as command tag but otherwise succeeds.
Here is an excerpt of Section 17.7 <commit statement> that I feel is
a) If any enforced constraint is not satisfied, then any changes to
SQL-data or schemas that were made by the current SQL-transaction are
canceled and an exception condition is raised: transaction rollback —
integrity constraint violation.
b) If any other error preventing commitment of the SQL-transaction has
occurred, then any changes to SQL-data or schemas that were made by the
current SQL-transaction are canceled and an exception condition is
raised: transaction rollback with an implementation-defined subclass value.
c) Otherwise, any changes to SQL-data or schemas that were made by the
current SQL-transaction are eligible to be perceived by all concurrent
and subsequent SQL-transactions.
It seems like this:
postgres=# \set VERBOSITY verbose
ERROR: 42601: syntax error at or near "error"
LINE 1: error;
LOCATION: scanner_yyerror, scan.l:1150
should actually produce something like this:
ERROR: 40P00: transaction cannot be committed
DETAIL: First error was "42601: syntax error at or near "error""
Is this reading correct?
If so, is this something we should fix?
|Next Message||Ranier Vilela||2020-02-11 22:01:41||Re: Postgres 32 bits client compilation fail. Win32 bits client is supported?|
|Previous Message||Alvaro Herrera||2020-02-11 21:40:38||Re: Memory-comparable Serialization of Data Types|