public inbox for [email protected]
help / color / mirror / Atom feedFrom: Sami Imseih <[email protected]>
To: Daniil Davydov <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
Date: Tue, 7 Apr 2026 11:33:31 -0500
Message-ID: <CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com> (raw)
In-Reply-To: <CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>
References: <CAA5RZ0s+kZZRMSF4HW7tZ9W2jS1o4B+Fg8dr5a-T6mANX+mdQA@mail.gmail.com>
<CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
<CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>
> > > 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?
Yeah, we could use dynamically named injection points, which I don't
see a precedent for. For example, we could construct a name like
"autovacuum-test-<relname>" and have the autovacuum code path
generate the injection point name dynamically based on the relation
being vacuumed. That way, the test only blocks on the specific table
it cares about.
But I don't think we need to do this now, since the test we are dealing
with does not need to wait for autovacuum to complete.
> 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.
That is an interesting idea which may be possible since we do reserve
a/v workers at startup with autovacuum_worker_slots. Although I am
not sure if we should be putting a feature that makes disabling
autovacuum globally supported behavior.
--
Sami
view thread (20+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected]
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
In-Reply-To: <CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox