Re: Adding facility for injection points (or probe points?) for more advanced tests
Nathan Bossart <nathandbossart@gmail.com>
From: Nathan Bossart <nathandbossart@gmail.com>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Michael Paquier <michael@paquier.xyz>, Dilip Kumar <dilipbalaut@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-04T22:31:02Z
Lists: pgsql-hackers
On Thu, Jan 04, 2024 at 06:04:20PM +0530, Ashutosh Bapat wrote: > 0003 and 0004 are using the extension in this module for some serious > testing. The name of the extension test_injection_point indicates that > it's for testing injection points and not for some serious use of > injection callbacks it adds. Changes 0003 and 0004 suggest otherwise. Yeah, I think test_injection_point should be reserved for testing the injection point machinery. > I suggest we move test_injection_points from src/test/modules to > contrib/ and rename it as "injection_points". The test files may still > be named as test_injection_point. The TAP tests in 0003 and 0004 once > moved to their appropriate places, will load injection_point extension > and use it. That way predefined injection point callbacks will also be > available for others to use. Rather than defining a module somewhere that tests would need to load, should we just put the common callbacks in the core server? Unless there's a strong reason to define them elsewhere, that could be a nice way to save a step in the tests. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
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