public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Sami Imseih <[email protected]>
Cc: pgsql-hackers <[email protected]>
Cc: Masahiko Sawada <[email protected]>
Cc: Daniil Davydov <[email protected]>
Subject: Re: Allow a condition string in an injection point
Date: Fri, 10 Apr 2026 07:38:38 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CAA5RZ0tsGHu2h6YLnVu4HiK05q+gTE_9WVUAqihW2LSscAYS-g@mail.gmail.com>
References: <CAA5RZ0tsGHu2h6YLnVu4HiK05q+gTE_9WVUAqihW2LSscAYS-g@mail.gmail.com>
On Thu, Apr 09, 2026 at 01:02:37PM -0500, Sami Imseih wrote:
> A follow-up to the discussion here [0], here is a patch that allows
> for an arbitrary string in injection points to be able to apply more
> granular filters for running an injection point. This will be useful
> for autovacuum testing as discussed in the referenced thread,
> and perhaps in some other places.
Are the patches under discussion required for v19 or is that something
that can wait before v20 opens for business? We have always required
a use-case in core before adding a new API in this module, to justify
its existence.
> The string is capped at 256 bytes which seems like a reasonable
> value. I considered using a flexible_array_member and to track
> the length, but that hardly seemed worth it at this stage.
This change is local to the module injection_points. That can be
changed at will even in the back-branches.
> A case I envision, and there could be more is only run
> the injection point for a specific rel.
>
> SELECT injection_points_attach('my-inj-pt', 'wait', 'tab1');
We may be able to simplify a couple more places that rely on multiple
INJECTION_POINT currently, with slightly different names. I doubt
these currently in the tree are worth changing. That would make
backpatches more invasive for the tests, which is more noise, so
most likely no.
> #ifdef USE_INJECTION_POINTS
> INJECTION_POINT("my-inj-pt", RelationGetRelationName(rel));
> #endif
Ahah, nice. You'd probably want to schema-qualify or database-quality
that anyway.
> Worth noting, the condition types were changed to bit flags since
> we may need to combine conditions such as local injection point
> and string.
It's definitely more useful to allow combinations of them in an AND
fashion (if two conditions are defined then check both, and allow the
point to run if both conditions pass). Just to say that what you are
doing looks sensible for me. And I find that pretty cool for its
simplicity and what it could provide for future tests.
@@ -322,6 +322,7 @@ InjectionPointAttach(const char *name,
strlcpy(entry->name, name, sizeof(entry->name));
strlcpy(entry->library, library, sizeof(entry->library));
strlcpy(entry->function, function, sizeof(entry->function));
+ memset(entry->private_data, 0, INJ_PRIVATE_MAXLEN);
if (private_data != NULL)
memcpy(entry->private_data, private_data, private_data_size);
Hmm, this could be qualified as a bug, and surely it's a good practice
to clean things on attach. I'll go backpatch that.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, 2-signature.asc)
download
view thread (3+ 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], [email protected]
Subject: Re: Allow a condition string in an injection point
In-Reply-To: <[email protected]>
* 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