concurrent index builds unneeded lock?

We just ran into a case where we were performing two concurrent index  
builds on two different tables in two different schemas in the same  
database (no relational constraints between them).

One of the index builds locked on the other.

The first index build started...
The second index build started...
The first one locked on the second one....
The second one finished...
The first one was allows to continue and finish.

quux=# select *  from pg_locks where pid IN (25264, 20108);  locktype  | database | relation | page | tuple |
virtualxid|  
 
transactionid | classid | objid | objsubid | virtualtransaction |   
pid  |           mode           | granted
------------+----------+----------+------+-------+------------ 
+---------------+---------+-------+----------+-------------------- 
+-------+--------------------------+--------- relation   |    16385 |    25852 |      |       |             
|               |         |       |          | 9/3041             |  
20108 | RowExclusiveLock         | t relation   |    16385 |    25861 |      |       |             
|               |         |       |          | 1/15735            |  
25264 | RowExclusiveLock         | t relation   |    16385 |    16421 |      |       |             
|               |         |       |          | 9/3041             |  
20108 | ShareUpdateExclusiveLock | t virtualxid |          |          |      |       | 9/3041      
|               |         |       |          | 9/3041             |  
20108 | ExclusiveLock            | t virtualxid |          |          |      |       | 1/15735     
|               |         |       |          | 1/15735            |  
25264 | ExclusiveLock            | t virtualxid |          |          |      |       | 9/3041      
|               |         |       |          | 1/15735            |  
25264 | ShareLock                | f relation   |    16385 |    16528 |      |       |             
|               |         |       |          | 1/15735            |  
25264 | ShareUpdateExclusiveLock | t
(7 rows)

Reading the comments in the concurrent index build code, it seems that  
in prep for phase 3 of the index build it looks for any open txns that  
could feasibly see deleted tuples prior to the snap.

I would think it would be txns that would be reading that table, but  
I'm thinking it is a bit to aggressive.  Am I reading the code wrong  
there?  I'm thinking it should be more selective about vxids it  
chooses to block on.  I'd expect it to block on vxids touching the  
same table only.

Thoughts?

--
Theo Schlossnagle
http://omniti.com/is/theo-schlossnagle
p: +1.443.325.1357 x201   f: +1.410.872.4911