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@xxxxxxxxxxx
510-665-1200 x179
www.bepress.com
bepress: sustainable scholarly publishing
