A solution to this problem is not versioning catalog tables but in-place updating them. Of course anther transaction that wants to update the same row in the catalog table should wait, which leads to bad concurrency. But this problem can be solved by commiting every DDL right after its execution successfully ends. Note that catalog table updators are DDL, not DML. I think that's why Oracle commits on execution of every DDL.
"Kangmo, Kim" <[EMAIL PROTECTED]> wrote in message ahple2$1rgh$[EMAIL PROTECTED]">news:ahple2$1rgh$[EMAIL PROTECTED]... > 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" <[EMAIL PROTECTED]> wrote in message > [EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > > > > 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 <[EMAIL PROTECTED]> +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 > > ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
