MIME-Version: 1.0
References: 
 <CAA5RZ0s+kZZRMSF4HW7tZ9W2jS1o4B+Fg8dr5a-T6mANX+mdQA@mail.gmail.com>
 <CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
In-Reply-To: 
 <CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
From: Daniil Davydov <3danissimo@gmail.com>
Date: Tue, 7 Apr 2026 21:06:09 +0700
Message-ID: 
 <CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
To: Masahiko Sawada <sawada.mshk@gmail.com>
Cc: Sami Imseih <samimseih@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/CAJDiXgjQEdssGEQ97UZEKBK5Qc5%3Durqi1qVLdsJwHbQtsBPH1g%40mail.gmail.com>
Precedence: bulk

Hi,

On Mon, Apr 6, 2026 at 7:24=E2=80=AFPM Sami Imseih <samimseih@gmail.com> wr=
ote:
>
> I noticed that the test introduced in parallel autovacuum in 1ff3180ca01 =
was
> very slow, but eventually succeeded. I tracked it down to the point in
> the test that is waiting for "parallel autovacuum worker updated cost par=
ams".

Good catch!

On Tue, Apr 7, 2026 at 2:29=E2=80=AFPM Masahiko Sawada <sawada.mshk@gmail.c=
om> wrote:
>
> On Mon, Apr 6, 2026 at 7:24=E2=80=AFPM Sami Imseih <samimseih@gmail.com> =
wrote:
> >
> > 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 po=
ints
and wait_for_autovacuum_complete call? If the reloption could override the =
GUC
parameter, then we could disable parallel a/v globally and turn it on for t=
he
particular table. In this case we can avoid such a problem.

--
Best regards,
Daniil Davydov