"Kevin Grittner" <kevin.gritt...@wicourts.gov> writes: > Eliminating null columns and mangling column headers for length, I > get this: > locktype | tranid | virtualx | pid | mode | gr > transactionid | 39773877 | 63/15761 | 11157 | ShareLock | f > transactionid | 39773877 | 4/10902 | 6421 | ExclusiveLock | t > So it looks like two locks on the same transaction ID by different > transactions. How does that happen?
That's perfectly normal --- it indicates that pid 11157 is waiting for a row-level lock that's currently held by pid 6421. We translate row-level locking delays into waits for XID locks in order to limit the number of distinct locks that have to be remembered in the shared lock table. (We'd soon blow out shared memory if per-row lock data had to be kept there.) As Peter stated, there's no evidence of an actual problem in this bug report. I'd go looking for clients sitting with open transactions... regards, tom lane -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs