Re: test_autovacuum/001_parallel_autovacuum is broken

From: Alexander Lakhin <exclusion(at)gmail(dot)com>
To: Sami Imseih <samimseih(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Cc: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Daniil Davydov <3danissimo(at)gmail(dot)com>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
Date: 2026-04-09 18:00:00
Message-ID: 525d0f48-93f7-493f-a988-f39b460a79bc@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matheus Alcantara 2026-04-09 18:00:34 docs: Include database collation check on SQL from alter_collation.sgml
Previous Message Andrey Borodin 2026-04-09 17:55:01 Re: Compress prune/freeze records with Delta Frame of Reference algorithm