Michael Paquier <mich...@paquier.xyz> writes:
> On Thu, Mar 14, 2024 at 06:19:38PM -0400, Tom Lane wrote:
>> I wonder if it'd be wise to adjust the injection point stuff so that
>> it's active in only the specific database the injection point was
>> activated in.
> It can be made optional by extending InjectionPointAttach() to
> specify a database OID or a database name. Note that
> 041_checkpoint_at_promote.pl wants an injection point to run in the
> checkpointer, where we don't have a database requirement.
> Or we could just disable runningcheck because of the concurrency
> requirement in this test. The test would still be able to run, just
> less times.
No, actually we *must* mark all these tests NO_INSTALLCHECK if we
stick with the current definition of injection points. The point
of installcheck mode is that the tests are supposed to be safe to
run in a live installation. Side-effects occurring in other
databases are completely not OK.
I can see that some tests would want to be able to inject code
cluster-wide, but I bet that's going to be a small minority.
I suggest that we invent a notion of "global" vs "local"
injection points, where a "local" one only fires in the DB it
was defined in. Then only tests that require a global injection
point need to be NO_INSTALLCHECK.
regards, tom lane
