The following bug has been logged online:
Bug reference: 5443
Logged by: Claudio
Email address: claudio@livra.com
PostgreSQL version: 8.3.7
Operating system: CentOS
Description: Undetected deadlock situation
Details:
During a massive update of a table A, a single-row update of table A in
another session created an undetected deadlock situation, as evidenced by
the following locks (taken from pg_locks):
locktype | database | relation | page | tuple | virtualxid |
transactionid | classid | objid | objsubid | virtualtransaction | pid |
mode | granted
transactionid | | | | | |
39773877 | | | | 63/15761 | 11157 |
ShareLock | f
transactionid | | | | | |
39773877 | | | | 4/10902 | 6421 |
ExclusiveLock | t
Only the deadlocked locks have been pasted, but I have saved the entire lock
list in case you need it.
It *might* be related to bug #3883 (
http://archives.postgresql.org/pgsql-hackers/2008-01/msg00873.php ) but it's
not clear. What makes me think so is that I've carefully set everything up
so that those updates make heavy use of HOT, and, if I'm not mistaken, HOT
does on-demand "vacuuming" of other dead HOT, so it *might* be calling
LockBufferForCleanup (I'm not familiar with the code though).