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

> > > I think we can remove the second wait_for_autovacuum_complete()
> > > call in the test, as all we really need is to wait_for_log to guarantee
> > > the cost parameters were updated. No need to wait for the autovacuum
> > > to complete.
> >
> > It sound like a good idea. In the test 2, we make garbage tuples on
> > test_autovac table but it doesn't necessarily mean that autovacuum
> > would work only on that table. Also given that the purpose of this
> > test is to check the propagation works fine, we can verify it whatever
> > tables eligible for parallel vacuum.
> >
>
> Yeah, we only need to ensure that there will be free parallel workers in
> bgworkers pool. Since only autovacuum can launch parallel workers in this
> test, I think everything is OK.
>
> 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.

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.

> 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.

--
Sami