Re: test_autovacuum/001_parallel_autovacuum is broken

Hi,

On Tue, Apr 7, 2026 at 11:33 PM Sami Imseih <samimseih(at)gmail(dot)com> wrote:
>
> > The proposed patch fixes the problem, but I am thinking about possible new
> > tests for parallel a/v. What if some of them will require both injection points
> > and wait_for_autovacuum_complete call?
>
> Yeah, we could use dynamically named injection points, which I don't
> see a precedent for. For example, we could construct a name like
> "autovacuum-test-<relname>" and have the autovacuum code path
> generate the injection point name dynamically based on the relation
> being vacuumed. That way, the test only blocks on the specific table
> it cares about.
>

I am afraid that this would be too rough a workaround for this problem..

> But I don't think we need to do this now, since the test we are dealing
> with does not need to wait for autovacuum to complete.

Sure! But this test needs to be slightly reworked in the future.

> > If the reloption could override the GUC
> > parameter, then we could disable parallel a/v globally and turn it on for the
> > particular table. In this case we can avoid such a problem.
>
> That is an interesting idea which may be possible since we do reserve
> a/v workers at startup with autovacuum_worker_slots. Although I am
> not sure if we should be putting a feature that makes disabling
> autovacuum globally supported behavior.

Hm, I think I didn't reveal my thoughts enough.
Let me describe current logic in short : each a/v worker now can take from
bgworkers pool as many parallel workers as the GUC parameter
(autovacuum_max_parallel_workers) allows.

We also have an "autovacuum_parallel_workers" reloption that can additionally
limit the number of parallel workers for the table. Default value of the
reloption is "-1" which means "use the GUC parameter's value". I.e. when we are
setting the GUC parameter to N, then every table automatically allows N
parallel a/v workers. If autovacuum_max_parallel_workers = 0 then no one can
launch parallel workers for autovacuum, even if reloption is > 0. Thus,
autovacuum_max_parallel_workers is the main limiter during the number of
parallel workers calculation.

But I suggest an alternative idea - allow reloption to override GUC parameter.
So even if autovacuum_max_parallel_workers is 0 we still can enable parallel
a/v for a particular table via reloption.

This approach allows us to rework the test as follows :
1) Keep the default value of GUC parameter which means that no table allows
parallel a/v.
2) Set reloption of a particular table to N (allow parallel a/v for this and
only this table).

This approach may also be very useful in large productions. You can read
discussion about it from here [1] up to the end of the thread. Since the
question is still open, all feedback is welcome!

[1] https://www.postgresql.org/message-id/CAJDiXgj3A%3DwNC-S0z3TixmnVUkifs%3D07yLLHJ7_%2BdDsakft1tA%40mail.gmail.com

--
Best regards,
Daniil Davydov