Hi, On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <[email protected]> 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".
Good catch! On Tue, Apr 7, 2026 at 2:29 PM Masahiko Sawada <[email protected]> wrote: > > On Mon, Apr 6, 2026 at 7:24 PM Sami Imseih <[email protected]> wrote: > > > > 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. > Yeah, we only need to ensure that there will be free parallel workers in bgworkers pool. Since only autovacuum can launch parallel workers in this test, I think everything is OK. The proposed patch fixes the problem, but I am thinking about possible new tests for parallel a/v. What if some of them will require both injection points and wait_for_autovacuum_complete call? If the reloption could override the GUC parameter, then we could disable parallel a/v globally and turn it on for the particular table. In this case we can avoid such a problem. -- Best regards, Daniil Davydov
