On cvs head, I can get "tuple concurrently updated" if two separate
transactions are both trying to drop the same index:
8<----------------------------
<psql session #1> contrib_regression=# create table t(f1 int); CREATE TABLE contrib_regression=# create index idx1
ont(f1); CREATE INDEX contrib_regression=# begin; BEGIN contrib_regression=# drop index idx1; DROP INDEX
<psql session #2> contrib_regression=# drop index idx1;
<psql session #1> contrib_regression=# commit; COMMIT
<psql session #2> ERROR: tuple concurrently updated
8<----------------------------
The backtrace for session #2 looks like:
8<----------------------------
#0 errfinish (dummy=0) at elog.c:293
#1 0x00000000006fb15d in elog_finish (elevel=20, fmt=0x73bda1 "tuple
concurrently updated") at elog.c:937
#2 0x000000000046c25f in simple_heap_delete (relation=0x2aaaaaac4990,
tid=0xba8e44) at heapam.c:2006
#3 0x00000000004c15cb in recursiveDeletion (object=0x7fffb9f7e5e0,
behavior=DROP_RESTRICT, msglevel=18, callingObject=0x0, oktodelete=0xba90a0, depRel=0x2aaaaaac4990,
alreadyDeleted=0x0) at dependency.c:657
#4 0x00000000004c0be5 in performDeletion (object=0x7fffb9f7e5e0,
behavior=DROP_RESTRICT) at dependency.c:177
#5 0x0000000000533863 in RemoveIndex (relation=0xba8d78,
behavior=DROP_RESTRICT) at indexcmds.c:1133
#6 0x00000000006474d5 in ProcessUtility (parsetree=0xb7dbd0,
queryString=0xba8ce8 "drop index idx1;", params=0x0, isTopLevel=1 '\001', dest=0xb7dc68,
completionTag=0x7fffb9f7eb40
"") at utility.c:608
#7 0x0000000000645bf7 in PortalRunUtility (portal=0xbb0d08, [...]
8<----------------------------
The comments for simple_heap_delete say:
/* * simple_heap_delete - delete a tuple * * This routine may be used to delete a tuple when concurrent updates of
*the target tuple are not expected (for example, because we have a * lock on the relation associated with the tuple).
Anyfailure is * reported via ereport(). */
So the question is -- is the comment wrong, or is this a bug, or am I
not just plain misunderstanding something ;-)
The reason I ask is that someone contacted me who is seeing this on a
production system, and the abort on session #2 is rolling back a large
bulkload.
Thanks,
Joe
