> > 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.
This is v20. One of the use-case is discussed here [1]. When testing of
autovacuum for a specific table, we need a way to run the injection point
for that table only, else we end up running the point it for all tables. This
is especially true for check-world where other non-related tables are
being autovacuumed. So this gives more granular control.
> > 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.
yes, I did test with some other new hypothetical condition in the future and
it was simple to plug it in to the code at that point.
> @@ -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.
It did not matter before this new condition type since the private_data
was never NULL. Not the case with this patch, as it caused inection_points test
regressions with this change. So, yeah, it's a latent bug.
--
Sami
[1] [https://www.postgresql.org/message-id/CAA5RZ0tExiffcu7qvrUbpq_qqz%3DzCD2aJ5_Qigo6eP2kgTx3eQ%40mail.gmail.com]
