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)
```

--
Kevin M. Goess
Software Engineer
Berkeley Electronic Press
kgoess(at)bepress(dot)com

510-665-1200 x179
www.bepress.com

bepress: sustainable scholarly publishing