Hi hackers,
I wonder if it is considered as correct behavior that transaction
conflict detection depends on presence of primary key:
create table t(pk integer, val integer);
insert into t values (1,0),(2,0);
Session1: begin isolation level serializable;
Session2: begin isolation level serializable;
Session1: update t set val=val+1 where pk=1;
Session2: update t set val=val+1 where pk=2;
Session1: commit;
Session2: commit;
ERROR: could not serialize access due to read/write dependencies among
transactions
DETAIL: Reason code: Canceled on identification as a pivot, during
commit attempt.
HINT: The transaction might succeed if retried.
Now let's repeat the same scenario but with "pk" declared as primary key:
create table t(pk integer primary key, val integer);
insert into t values (1,0),(2,0);
Session1: begin isolation level serializable;
Session2: begin isolation level serializable;
Session1: update t set val=val+1 where pk=1;
Session2: update t set val=val+1 where pk=2;
Session1: commit;
Session2: commit;
Now both transactions are succeeded.
Please notice, that even if it is expected behavior, hint in error
message is not correct, because transaction is actually aborted and
there is no chance to retry it.
--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
