Обсуждение: Potential deadlock with auto-analyze
It says here that CVS HEAD has a deadlock risk: http://www.pgbuildfarm.org/cgi-bin/show_log.pl?nm=chinchilla&dt=2008-06-09%2008:16:01 The problem manifested while attempting to drop a GIN index (though I doubt GIN is specially at fault): [484ceb40.47da:169] ERROR: deadlock detected [484ceb40.47da:170] DETAIL: Process 18394 waits for AccessExclusiveLock on relation 41759 of database 41648; blocked byprocess 18401.Process 18401 waits for AccessShareLock on relation 41766 of database 41648; blocked by process 18394.Process18394: DROP INDEX text_idx;Process 18401: autovacuum: ANALYZE public.test__int [484ceb40.47da:171] HINT: See server log for query details. [484ceb40.47da:172] STATEMENT: DROP INDEX text_idx; We need to fix that --- having DDL randomly fail is not going to go over well with autovacuum users. I don't have time to look into it just now, but I rather suspect that what's happening is that the DROP tries to lock the index first and the table second, since it can't find out which table is involved without looking at the index. So it can deadlock against anything going in the more-normal direction. If that's the right diagnosis, we probably ought to try to fix DROP INDEX to not do that, since it could deadlock against any number of things not just autovac. But there's another question here: can we make autovac lose the deadlock war, instead of the user process? regards, tom lane
Tom Lane wrote: > If that's the right diagnosis, we probably ought to try to fix DROP > INDEX to not do that, since it could deadlock against any number of > things not just autovac. But there's another question here: can we > make autovac lose the deadlock war, instead of the user process? Hmm, I thought autovacuum was already supposed to lose on deadlock. Perhaps it's only considering VACUUM though and not analyze ... [checks] nope, that doesn't seem to be it. -- Alvaro Herrera http://www.CommandPrompt.com/ PostgreSQL Replication, Consulting, Custom Development, 24x7 support