| From: | Sami Imseih <samimseih(at)gmail(dot)com> |
|---|---|
| To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
| Cc: | Alexander Lakhin <exclusion(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, Daniil Davydov <3danissimo(at)gmail(dot)com> |
| Subject: | Re: test_autovacuum/001_parallel_autovacuum is broken |
| Date: | 2026-04-09 20:14:15 |
| Message-ID: | CAA5RZ0uOSnAKX4xF0PBSZqYCxUMTnheAKkcsiQDNYTZg20ognQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> Optionally, we can change the comment above to something like this:
> # Wait until the parallel autovacuum on the table completes and reports the
> # number of launched workers, which must correspond to the value specified in
> # the reloption.
Made the comment less verbose but in the same spirit as the above.
> > > One way to fix the test is to replace log_contains() with
> > > wait_for_log(). We can also remove wait_for_autovacuum_complete()
> > > logic altogether.
> >
> > +1. I was going to reply with exactly this. Attached is the fix.
>
> Thank you for the patch! I agree with the overall idea. Since we
> enable autovacuum log only the test_autovac table, just checking
> autovacuum log works as expected.
>
> I think we can simplify the test further by removing the logic around
> the av_count variable.
removed av_count and pg_stat_user_tables query, but hardened the
regexp a bit to ensure that the parallel logging is for the test_autovac
table. It gives the same assurance as counting pg_stat_user_tables
and will be better if we add another parallel test table in the future.
--
Sami
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Fix-unstable-log_contains-in-parallel-autovacuum-.patch | application/octet-stream | 3.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2026-04-09 20:55:14 | Heads Up: cirrus-ci is shutting down June 1st |
| Previous Message | SATYANARAYANA NARLAPURAM | 2026-04-09 19:42:23 | Re: SQL:2011 Application Time Update & Delete |