Re: Adding facility for injection points (or probe points?) for more advanced tests - Mailing list pgsql-hackers

From Ashutosh Bapat
Subject Re: Adding facility for injection points (or probe points?) for more advanced tests
Date
Msg-id CAExHW5vyURNaht1YYJfZMk-Kyh=TD6FhE4NEi5zTAhnOj0qwcA@mail.gmail.com
Whole thread Raw
In response to Re: Adding facility for injection points (or probe points?) for more advanced tests  (Michael Paquier <michael@paquier.xyz>)
Responses Re: Adding facility for injection points (or probe points?) for more advanced tests
List pgsql-hackers
On Fri, Nov 24, 2023 at 7:37 PM Michael Paquier <michael@paquier.xyz> wrote:
>
> On Fri, Nov 24, 2023 at 04:37:58PM +0530, Ashutosh Bapat wrote:
> > Interesting idea. For that the callback needs to know the injection
> > point name. At least we should pass that to the callback. It's trivial
> > thing to do.
>
> This is what's done from the beginning, as well as of 0001 in the v5
> series:
> +INJECTION_POINT(name);
> [...]
> +   injection_callback(name);

In my first look I missed the actual call to the injection callback in
InjectionPointRun()
injection_callback(name);

Sorry for that.

The way I see it is that an extension using this functionality will
create an auxiliary lookup table keyed by the injection point name to
obtain the injection point specific arguments (sleep time, count etc.)
in the shared memory or local memory. Every time an injection callback
is called it will consult this look up table to get the arguments.
That looks ok to me. There might be other ways to achieve the same
effect. We will learn and absorb whatever benefits core and the users.
I like that.

>
> > That might work, but in order to run tests in that directory one has
> > to also install the extension. Do we have precedence for such kind of
> > dependency?
>
> Yes, please see EXTRA_INSTALL in some of the Makefiles.  This can
> install stuff from paths different than the location where the tests
> are run.

WFM then.

>
> >> and that there are no string objections, so feel free
> >> to comment.
> >
> > Let's get some more opinions on the design. I will review the detailed
> > code then.
>
> Sure.  Thanks.
>
> >> I don't want to propose 0003 in the tree, just an improved version of
> >> 0004 for the test coverage (still need to improve that).
> >
> > Are you working on v6 already?
>
> No, what would be the point at this stage?  I dont have much more to
> add to 0001 and 0002 at the moment, which focus on the core of the
> problem.

Since you wroten "(still need to improve ...) I thought you are
working on v6. No problem. Sorry for the confusion.

--
Best Wishes,
Ashutosh Bapat



pgsql-hackers by date:

Previous
From: Amit Kapila
Date:
Subject: Re: pgoutput incorrectly replaces missing values with NULL since PostgreSQL 15
Next
From: Masahiko Sawada
Date:
Subject: Re: [PoC] Improve dead tuple storage for lazy vacuum