Gregory Stark <[EMAIL PROTECTED]> writes: > The pid it's waiting on is long since gone but looks like it was probably an > autovacuum process. I have a vague recollection that you had rigged CREATE > INDEX CONCURRENTLY to ignore vacuum processes when checking for conflicting > processes. Since any such process will be blocked on our session-level > ShareUpdateExclusiveLock it will always cause a deadlock and we would rather > it just hang out and wait until our index build is finished.
OK, after reading the code some more I think I've got the point. The scenario is that autovacuum is waiting to get ShareUpdateExclusiveLock (it can't already have it, because the CREATE INDEX CONCURRENTLY does) and then one of C.I.C's three wait steps decides it has to wait for the autovacuum. It cannot be one of the first two, because those only block for xacts that *already have* a conflicting lock. The problem must be at the third wait step, which waits out all xacts that might conceivably be interested in recently-dead tuples that are not in the index. Now an unindexed dead tuple is not a problem from vacuum's point of view, nor does ANALYZE care, so AFAICS there is no need for this step to wait for autovacuum processes --- nor indeed for manual vacuums. So we can avoid the deadlock if we just exclude those processes from the list of ones to wait for. I suggest we extend GetCurrentVirtualXIDs() with an additional parameter includeVacuums, and have it skip vacuum procs if that's set. (Hmm, maybe a more flexible approach is to make the parameter a bitmask, and ignore any procs for which param & vacuumFlags is not zero.) Comments? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 7: You can help support the PostgreSQL project by donating at http://www.postgresql.org/about/donate