Re: test_autovacuum/001_parallel_autovacuum is broken

Hi,

On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <samimseih(at)gmail(dot)com> 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 <sawada(dot)mshk(at)gmail(dot)com> wrote:
>
> On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <samimseih(at)gmail(dot)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 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