Re: test_autovacuum/001_parallel_autovacuum is broken

From: Sami Imseih <samimseih(at)gmail(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Daniil Davydov <3danissimo(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: test_autovacuum/001_parallel_autovacuum is broken
Date: 2026-04-08 14:52:39
Message-ID: CAA5RZ0tH1Wb+5b+WW+6Cs9jFRZ215n5g=ZsB9KL7zmp5gBi+kQ@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On Tue, Apr 07, 2026 at 01:02:49PM -0500, Sami Imseih wrote:
> > 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.
>
> Yeah, InjectionPointConditionType was designed with these types of
> extensions in mind in terms of conditions you want to assign to a
> point name when attaching it, with the check happening in the callback
> attached when it is run. It should not be complicated to extend
> injection_points_attach(), just pass down a string that it then
> translated to an OID, or you could use a different grammar as well.
> One thing that I'd be careful about is to handle that with one
> argument in the SQL attach function, with the condition data given as
> an input string. One grammar that Alexander K. designed at some point
> for some of the facilities he had proposed was a JSON input, but
> that's an implementation artifact.
>
> Doing something as a separate module/library would be also fine. We
> do that for the AIO tests.

I think we can enhance these tests using a separate module as Daniil is
suggesting, but we should probably get 0001 committed first and then
have a quick follow-up. What do you think?

--
Sami

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ashutosh Sharma 2026-04-08 14:55:00 Re: synchronized_standby_slots behavior inconsistent with quorum-based synchronous replication
Previous Message Nathan Bossart 2026-04-08 14:49:01 Re: pg_plan_advice