process deadlocking on its own transactionid?

We're seeing a problem with some of our processes hanging on locks.  The select below makes it look like it's *waiting* for a ShareLock on transactionid, but it *has* an ExclusiveLock on the same value in virtualxid.  

That makes it look like the process has deadlocked on its own transactionid.  Or are we reading the results of this query wrong, and this is expected behavior, and our problem lies elsewhere? (Yes, the process is doing a "select for update" on this context_objects table according to pg_stat_activity)

production=> select locktype, database, relname, relation, virtualxid, virtualtransaction, pid, mode, granted 

from pg_locks left outer join pg_class on pg_class.oid = pg_locks.relation 

where pid = 2288;

   locktype    | database |       relname        | relation |  virtualxid  | virtualtransaction | pid  |      mode       | granted 

---------------+----------+----------------------+----------+--------------+--------------------+------+-----------------+---------

 relation      |    41194 | context_objects_pkey | 95318843 |              | 123/45694692       | 2288 | AccessShareLock | t

 relation      |    41194 | context_objects      |    41553 |              | 123/45694692       | 2288 | RowShareLock    | t

 virtualxid    |          |                      |          | 123/45694692 | 123/45694692       | 2288 | ExclusiveLock   | t

 transactionid |          |                      |          |              | 123/45694692       | 2288 | ShareLock       | f

 tuple         |    41194 | context_objects      |    41553 |              | 123/45694692       | 2288 | ExclusiveLock   | t

(5 rows)

```