Gregory Stark <stark@enterprisedb.com> 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
