The following bug has been logged online: Bug reference: 5443 Logged by: Claudio Email address: clau...@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). -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
