Re: Adding facility for injection points (or probe points?) for more advanced tests
Andres Freund <andres@anarazel.de>
From: Andres Freund <andres@anarazel.de>
To: Michael Paquier <michael@paquier.xyz>
Cc: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2023-11-11T02:32:27Z
Lists: pgsql-hackers
Hi, On 2023-10-25 13:13:38 +0900, Michael Paquier wrote: > So, please find attached a patch set that introduces an in-core > facility to be able to set what I'm calling here an "injection point", > that consists of being able to register in shared memory a callback > that can be run within a defined location of the code. It means that > it is not possible to trigger a callback before shared memory is set, > but I've faced far more the case where I wanted to trigger something > after shmem is set anyway. Persisting an injection point across > restarts is also possible by adding some through an extension's shmem > hook, as we do for custom LWLocks for example, as long as a library is > loaded. I would like to see a few example tests using this facility - without that it's a bit hard to judge how the impact on core code would be and how easy tests are to write. It also seems like there's a few bits and pieces missing to actually be able to write interesting tests. It's one thing to be able to inject code, but what you commonly want to do for tests is to actually wait for such a spot in the code to be reached, then perhaps wait inside the "modified" code, and do something else in the test script. But as-is a decent amount of C code would need to be written to write such a test, from what I can tell? Greetings, Andres Freund
Commits
-
ci: Enable injection points in builds
- 183b6f73b04e 17.0 landed
-
Fix two memcpy() bugs in the new injection point code
- 0eb23285a257 17.0 landed
-
Add test module injection_points
- 49cd2b93d7db 17.0 landed
-
Add backend support for injection points
- d86d20f0ba79 17.0 landed
-
Refactor code checking for file existence
- e72a37528dda 17.0 landed