"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 on t(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). Any failure 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