"tuple concurrently updated" during index deletion

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