Hello,
07.04.2026 05:23, Sami Imseih 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".
I've found another issue with the test manifested on buildfarm, at least
at [1]:
[06:54:07.738](4.121s) not ok 1
[06:54:07.769](0.031s) # Failed test at /home/bf/bf-build/flaviventris/HEAD/pgsql/src/test/modules/test_autovacuum/t/001_parallel_autovacuum.pl line 133.
### Stopping node "main" using mode fast
The corresponding test code:
# Wait until the parallel autovacuum on table is completed. At the same time,
# we check that the required number of parallel workers has been started.
wait_for_autovacuum_complete($node, $av_count);
ok( $node->log_contains(
qr/parallel workers: index vacuum: 2 planned, 2 launched in total/,
$log_offset));
but regress_log_001_parallel_autovacuum contains this string:
2026-04-07 06:54:07.736 CEST [1825954][autovacuum worker][102/5:0] LOG: automatic vacuum of table "postgres.public.test_autovac": index scans: 1
...
parallel workers: index vacuum: 2 planned, 2 launched in total
though the timestamp difference is only 2 ms. I tried the following
modification:
@@ -1222,6 +1222,7 @@ heap_vacuum_rel(Relation rel, const VacuumParams *params,
(double) dead_items_max_bytes / (1024 * 1024));
appendStringInfo(&buf, _("system usage: %s"), pg_rusage_show(&ru0));
+pg_usleep(300000);
ereport(verbose ? INFO : LOG,
(errmsg_internal("%s", buf.data)));
pfree(buf.data);
and it makes the test fail for me on each run.
Could you please look if this can be fixed too?
[1]
https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=flaviventris&dt=2026-04-07%2004%3A41%3A09 Best regards,
Alexander
