Re: POC: Parallel processing of indexes in autovacuum

On Fri, Apr 3, 2026 at 6:45 AM Daniil Davydov <3danissimo@gmail.com> wrote:
>
> Hi,
>
> On Fri, Apr 3, 2026 at 6:00 AM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
> >
> > On Thu, Apr 2, 2026 at 8:10 AM Daniil Davydov <3danissimo@gmail.com> wrote:
> > >
> > > I think we should add some cleanup for autovacuum near the ParallelContext
> > > cleanup, since they are interconnected. I also want to return our tests that
> > > are triggering ERROR/PANIC in the leader worker in order to check whether all
> > > resources are released. I hope I will be able to get to that by tomorrow
> > > evening.
> >
> > I think that the beginning of vacuum loop (in PG_TRY() block in
> > vacuum()) seems better place as we're resetting vacuum delay
> > parameters:
> >
> >         in_vacuum = true;
> >         VacuumFailsafeActive = false;
> >         VacuumUpdateCosts();
> >         VacuumCostBalance = 0;
> >         VacuumCostBalanceLocal = 0;
> >         VacuumSharedCostBalance = NULL;
> >         VacuumActiveNWorkers = NULL;
> >
>
> I am still thinking that this pointer is related to the ParallelContext, and it
> is a bit confusing that we can manipulate it outside all "parallel" logic.
> Since this variable points to the DSM it looks very natural for me if its
> lifetime will be similar to the DSM. Please, see attached patch, that resets
> this pointer during dsm detaching.

Sounds a reasonable apporach.

Regarding the regression tests, ISTM we no longer need
'autovacuum-leader-before-indexes-processing' injection point since it
currently tests that parallel workers update their delay parameters
during the initialization (i.e., in parallel_vacuum_main()). In order
to verify the behavior of workers updating their delay parameters
while processing indexes, we would need another injection ponit to
stop parallel workers, which seems overkill to me. So I removed it but
the test still covers the propagation logic.

Regarding the patch, I don't think it's a good idea to include
bgworker_internals.h from reloptions.c:

@@ -28,6 +28,7 @@
 #include "commands/defrem.h"
 #include "commands/tablespace.h"
 #include "nodes/makefuncs.h"
+#include "postmaster/bgworker_internals.h"
 #include "storage/lock.h"
 #include "utils/array.h"
 #include "utils/attoptcache.h"
@@ -236,6 +237,15 @@ static relopt_int intRelOpts[] =
        },
        SPGIST_DEFAULT_FILLFACTOR, SPGIST_MIN_FILLFACTOR, 100
    },
+   {
+       {
+           "autovacuum_parallel_workers",
+           "Maximum number of parallel autovacuum workers that can be
used for processing this table.",
+           RELOPT_KIND_HEAP,
+           ShareUpdateExclusiveLock
+       },
+       -1, -1, MAX_PARALLEL_WORKER_LIMIT
+   },

I'd leave the maximum value as 1024.

I've attached patch and please check it. I think it's a good shape and
I'm going to push it next Monday barrying objections.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com