Hi,
On Wed, Apr 8, 2026 at 1:03 AM Sami Imseih <samimseih@gmail.com> wrote:
>
> > I am afraid that this would be too rough a workaround for this problem..
>
> Perhaps, but I don't see it being unreasonable for injection points.
>
> I guess we can also think about expanding InjectionPointCondition to
> handle other types of conditions, maybe OID??, to filter when running
> the point.
>
Hm, sounds reasonable.
I am thinking about how to make it less invasive. For example, we can write an
extension for this test (like many other tests do). The extension could allow
us to specify the oid of the table we are interested in. See attached patch
that demonstrates my idea. What do you think?
>
> > 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.
>
> autovacuum_max_parallel_workers being the limiter is a desirable
> attribute, otherwise
> it will allow users to disable the GUC and set whatever they want on a
> per table level,
> only guarded by max_parallel_workers. That to me sounds pretty easy to
> misconfigure
> and manage.
Yes, this is the main argument against this idea. However, in the thread that
I mentioned I tried to give arguments why this might be extremely convenient
for users with large databases.
--
Best regards,
Daniil Davydov
