COMMIT leads to ROLLBACK

Поиск
Список
Период
Сортировка
От Gurjeet Singh
Тема COMMIT leads to ROLLBACK
Дата
Msg-id 65937bea0605210957p5e5fd6b0y11344273faa1f4e7@mail.gmail.com
обсуждение исходный текст
Ответы Re: COMMIT leads to ROLLBACK
Re: COMMIT leads to ROLLBACK
Список pgsql-hackers
Hi All,
   While trying to implement a recent TODO item, I noticed this behaviour:

test=# drop table t2; drop table t1;
DROP TABLE
DROP TABLE
test=# create table t1(a int primary key );
NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index
"t1_pkey" for table "t1"
CREATE TABLE
test=# create table t2( a int references t1(a ));
CREATE TABLE
test=# begin;
BEGIN
test=# insert into t2 values( 5 );
ERROR:  insert or update on table "t2" violates foreign key constraint
"t2_a_fkey"
DETAIL:  Key (a)=(5) is not present in table "t1".
test=# select * from t2;
ERROR:  current transaction is aborted, commands ignored until end of
transaction block
test=# commit;
ROLLBACK
   Issuing a COMMIT or an END as the last command leads to a
ROLLBACK. Although the behaviour is correct, shouldn't the user be
atleast warned about having issued a wrong command to end the
transaction? An application might believe that everything was OK if it
recieves a SUCCESS for a COMMIT, although the data (INSERT or any
other subsequent DML) never made it to the data-files because the
COMMIT was converted into a ROLLBACK!!!
   Either:     1) COMMIT in an aborted transaction should lead to an 'ERROR:
Cannot COMMIT an aborted transaction.'     2) At least a 'WARNING: transaction is being rolled back to last
known consistent state.' should precede the success (ROLLBACK)
message.

Regards,
Gurjeet.


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Martijn van Oosterhout
Дата:
Сообщение: Re: Compression and on-disk sorting
Следующее
От: Tom Lane
Дата:
Сообщение: Re: COMMIT leads to ROLLBACK