On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <[email protected]> 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
From 2ebc8df9f7ce757820247d6e97b4109f95ce85f6 Mon Sep 17 00:00:00 2001 From: Masahiko Sawada <[email protected]> Date: Mon, 6 Apr 2026 21:38:15 -0700 Subject: [PATCH] Remove an unstable wait from parallel autovacuum regression test. MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The test 001_parallel_autovacuum.pl verified that vacuum delay parameters are propagated to parallel vacuum workers by using injection points. It previously waited for autovacuum to complete on the test_autovac table. However, since injection points are cluster-wide, an autovacuum worker could be triggered on tables in other databases (e.g., template1) and get stuck at the same injection point. This could lead to a timeout when the test waits for the expected table's autovacuum to finish. This commit removes the wait for autovacuum completion from this specific test case. Since the primary goal is to verify the propagation of parameter updates—which is already confirmed via log messages—waiting for the entire vacuum process to finish is unnecessary and prone to instability in concurrent test environments. Author: Sami Imseih <[email protected]> Discussion: https://postgr.es/m/caa5rz0s+kzzrmsf4hw7tz9w2js1o4b+fg8dr5a-t6manx+m...@mail.gmail.com --- src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl | 2 -- 1 file changed, 2 deletions(-) diff --git a/src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl b/src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl index c5a2e78246a..fc4dd22f5eb 100644 --- a/src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl +++ b/src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl @@ -177,8 +177,6 @@ $node->wait_for_log( qr/parallel autovacuum worker updated cost params: cost_limit=500, cost_delay=5, cost_page_miss=10, cost_page_dirty=10, cost_page_hit=10/, $log_offset); -wait_for_autovacuum_complete($node, $av_count); - # Cleanup $node->safe_psql( 'postgres', qq{ -- 2.53.0
