On Tue, Nov 2, 2021 at 2:46 PM Masahiko Sawada <sawada.m...@gmail.com> wrote: > > Anyway, I'll write a patch accordingly.
While writing a patch for these comments, I found another bug in parallel_processing_is_safe(): /* * Returns false, if the given index can't participate in parallel index * vacuum or parallel index cleanup */ static bool parallel_processing_is_safe(Relation indrel, LVShared *lvshared) { uint8 vacoptions = indrel->rd_indam->amparallelvacuumoptions; /* first_time must be true only if for_cleanup is true */ Assert(lvshared->for_cleanup || !lvshared->first_time); if (lvshared->for_cleanup) { /* Skip, if the index does not support parallel cleanup */ if (((vacoptions & VACUUM_OPTION_PARALLEL_CLEANUP) == 0) && ((vacoptions & VACUUM_OPTION_PARALLEL_COND_CLEANUP) == 0)) return true; It returns true in the above condition but it should return false since the index doesn't support parallel index cleanup at all. It seems that this bug was introduced by commit b4af70cb21 (therefore exists only in PG14) which flipped the return values of this function but missed one place. The index AMs that don't support parallel index cleanup at all are affected by this bug. Among the supported index AM in the core, hash indexes are affected but since they just return the number of blocks during vacuumcleanup it would not become a serious consequence. I've attached a patch to fix it. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
fix_parallel_processing_is_safe.patch
Description: Binary data