I guess two transactions updated a tuple concurrently.
Because versioning scheme allows old versions can be
read by another transaction, the old version can be updated too.
For example,
We have a row whose value is 1
create table t1 (i1 integer);
insert into t1 values(1);
And,
Tx1 executes update t1 set i1=2 where i1=1
Tx2 executes update t1 set i1=10 where i1=1
Now suppose that
Tx1 read i1 with value 1
Tx2 read i1 with value 1
Tx1 updates i1 to 2 by inserting 2 into t1 according to versioning scheme.
Tx2 tries to update i1 to 10 but fails because it is already updated by Tx1.
Because you created different index with different transaction,
The concurrently updated tuple cannot be any of index node.
If the index on the same class,
two concurrent CREATE INDEX command can update pg_class.relpages
at the same time.
I guess that is not a bug of pgsql, but a weak point of
MVCC DBMS.
"Curt Sampson" <cjs@cynic.net> wrote in message
news:Pine.NEB.4.44.0207180848400.681-100000@angelic.cynic.net...
>
> One of my machines has two CPUs, and in some cases I build a pair
> of indexes in parallel to take advantage of this. (I can't seem
> to do an ALTER TABLE ADD PRIMARY KEY in parallel with an index
> build, though.) Recently, though, I received the message "ERROR:
> simple_heap_update: tuple concurrently updated." Can anybody tell
> me more about this error and its consequences?
>
> cjs
> --
> Curt Sampson <cjs@cynic.net> +81 90 7737 2974 http://www.netbsd.org
> Don't you know, in this new Dark Age, we're all light. --XTC
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 5: Have you checked our extensive FAQ?
>
> http://www.postgresql.org/users-lounge/docs/faq.html