public inbox for [email protected]
help / color / mirror / Atom feedFrom: Daniil Davydov <[email protected]>
To: Sami Imseih <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
Date: Wed, 8 Apr 2026 00:27:32 +0700
Message-ID: <CAJDiXgibFmjCvpVojOGCU4DfaqJ3pE+p2BTn_spZNVKrbcGjLQ@mail.gmail.com> (raw)
In-Reply-To: <CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com>
References: <CAA5RZ0s+kZZRMSF4HW7tZ9W2jS1o4B+Fg8dr5a-T6mANX+mdQA@mail.gmail.com>
<CAD21AoDZG6CUE9by0T2N33Zedw4iH0JF=9YoCuniXcugO+ixog@mail.gmail.com>
<CAJDiXgjQEdssGEQ97UZEKBK5Qc5=urqi1qVLdsJwHbQtsBPH1g@mail.gmail.com>
<CAA5RZ0tATt=YNy9suA3svMAjw3oBDzxcw8+gMMVHbYG9NBQtRA@mail.gmail.com>
Hi,
On Tue, Apr 7, 2026 at 11:33 PM Sami Imseih <[email protected]> wrote:
>
> > 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.
>
I am afraid that this would be too rough a workaround for this problem..
> 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.
Sure! But this test needs to be slightly reworked in the future.
> > 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.
Hm, I think I didn't reveal my thoughts enough.
Let me describe current logic in short : each a/v worker now can take from
bgworkers pool as many parallel workers as the GUC parameter
(autovacuum_max_parallel_workers) allows.
We also have an "autovacuum_parallel_workers" reloption that can additionally
limit the number of parallel workers for the table. Default value of the
reloption is "-1" which means "use the GUC parameter's value". I.e. when we are
setting the GUC parameter to N, then every table automatically allows N
parallel a/v workers. If autovacuum_max_parallel_workers = 0 then no one can
launch parallel workers for autovacuum, even if reloption is > 0. Thus,
autovacuum_max_parallel_workers is the main limiter during the number of
parallel workers calculation.
But I suggest an alternative idea - allow reloption to override GUC parameter.
So even if autovacuum_max_parallel_workers is 0 we still can enable parallel
a/v for a particular table via reloption.
This approach allows us to rework the test as follows :
1) Keep the default value of GUC parameter which means that no table allows
parallel a/v.
2) Set reloption of a particular table to N (allow parallel a/v for this and
only this table).
This approach may also be very useful in large productions. You can read
discussion about it from here [1] up to the end of the thread. Since the
question is still open, all feedback is welcome!
[1] https://www.postgresql.org/message-id/CAJDiXgj3A%3DwNC-S0z3TixmnVUkifs%3D07yLLHJ7_%2BdDsakft1tA%40ma...
--
Best regards,
Daniil Davydov
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: <CAJDiXgibFmjCvpVojOGCU4DfaqJ3pE+p2BTn_spZNVKrbcGjLQ@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