public inbox for [email protected]  

help / color / mirror / Atom feed

From: Daniil Davydov <[email protected]>
To: Masahiko Sawada <[email protected]>
Cc: Sami Imseih <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
Date: Tue, 7 Apr 2026 21:06:09 +0700
Message-ID: <CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com> (raw)
In-Reply-To: <CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
References: <CAA5RZ0s+kZZRMSF4HW7tZ9W2jS1o4B+Fg8dr5a-T6mANX+mdQA@mail.gmail.com>
	<CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>

Hi,

On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <[email protected]> wrote:
>
> 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 params".

Good catch!

On Tue, Apr 7, 2026 at 2:29 PM Masahiko Sawada <[email protected]> wrote:
>
> On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <[email protected]> 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 points
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 the
particular table. In this case we can avoid such a problem.

--
Best regards,
Daniil Davydov

view thread (20+ messages)  latest in thread

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
  In-Reply-To: <CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox