MIME-Version: 1.0
References: 
 <CAA5RZ0s+kZZRMSF4HW7tZ9W2jS1o4B+Fg8dr5a-T6mANX+mdQA@mail.gmail.com>
 <CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
 <CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>
 <CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com>
In-Reply-To: 
 <CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Wed, 8 Apr 2026 00:27:32 +0700
Message-ID: 
 <CAJDiXgibFmjCvpVojOGCU4DfaqJ3pE+p2BTn_spZNVKrbcGjLQ@mail.gmail.com>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
To: Sami Imseih <samimseih@gmail.com>
Cc: Masahiko Sawada <sawada.mshk@gmail.com>,
 pgsql-hackers <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAJDiXgibFmjCvpVojOGCU4DfaqJ3pE%2Bp2BTn_spZNVKrbcGjLQ%40mail.gmail.com>
Precedence: bulk

Hi,

On Tue, Apr 7, 2026 at 11:33=E2=80=AFPM Sami Imseih <samimseih@gmail.com> w=
rote:
>
> > 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 injectio=
n 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 f=
or 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 additional=
ly
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 =3D 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 paramet=
er.
So even if autovacuum_max_parallel_workers is 0 we still can enable paralle=
l
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 an=
d
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