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