Re: Weird test mixup
От | Tom Lane |
---|---|
Тема | Re: Weird test mixup |
Дата | |
Msg-id | 2393552.1710458033@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: Weird test mixup (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: Weird test mixup
Re: Weird test mixup |
Список | pgsql-hackers |
Michael Paquier <michael@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
В списке pgsql-hackers по дате отправления: