We've observed a 9.0 database have undetected deadlocks repeatedly in hot standby mode.
I think what's happening is that autovacuum is kicking off a VACUUM of some system catalogs -- it seems to usually be pg_statistics' toast table actually. At the end of the vacuum it briefly gets the exclusive lock to truncate the table. On the standby it replays that and records the exclusive lock being taken. It then sees a cleanup record that pauses replay because a HS standby transaction is running that can see the xid being cleaned up. That transaction then blocks against the exclusive lock and deadlocks against recovery. We expect upgrading to 9.3 to fix the problem for us due to the xid feedback mechanism. But is this still a known problem when feedback is not enabled? And is it a problem we should try to find a backpatchable fix for? I'm pondering whether we really need to log the exclusive lock taken by vacuum when truncating. Worst case is a scan is in progress, perhaps we can make scans understand how to handle tables that have been truncated concurrently? We could always make the truncate replay command acquire the lock and release it itself right away. -- greg -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
