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