Re: test_autovacuum/001_parallel_autovacuum is broken - Mailing list pgsql-hackers

From Masahiko Sawada
Subject Re: test_autovacuum/001_parallel_autovacuum is broken
Date
Msg-id CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com
Whole thread Raw
In response to test_autovacuum/001_parallel_autovacuum is broken  (Sami Imseih <samimseih@gmail.com>)
Responses Re: test_autovacuum/001_parallel_autovacuum is broken
List pgsql-hackers
On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <samimseih@gmail.com> wrote:
>
> Hi,
>
> 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".

Thank you for the report.

>
> This portion of the test that is waiting for the cost params to propagate to the
> workers is getting stuck on wait_for_autovacuum_complete(). At the time
> it's stuck the injection point from the previous test
> autovacuum-start-parallel-vacuum
> is still active on template1 tables.
(snip)
> 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.

I've attached the patch, and am going to push it barring any objections.

Regards,

--
Masahiko Sawada
Amazon Web Services: https://aws.amazon.com

Attachment

pgsql-hackers by date:

Previous
From: Lukas Fittl
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?
Next
From: Zsolt Parragi
Date:
Subject: Re: Reduce timing overhead of EXPLAIN ANALYZE using rdtsc?