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: Michael Paquier <michael@paquier.xyz>
Cc: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-05T16:27:51Z
Lists: pgsql-hackers
On Fri, Jan 05, 2024 at 08:38:22AM +0900, Michael Paquier wrote: > On Thu, Jan 04, 2024 at 04:31:02PM -0600, Nathan Bossart wrote: >> 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. > > Nah, having some pre-existing callbacks existing in the backend is > against the original minimalistic design spirit. These would also > require an SQL interface, and the interface design also depends on the > functions registering them when pushing down custom conditions. > Pushing that down to extensions to do what they want will lead to less > noise, particularly if you consider that we will most likely want to > tweak the callback interfaces for backpatched bugs. That's also why I > think contrib/ is not a good idea, src/test/modules/ serving the > actual testing purpose here. Ah, so IIUC we'd have to put some functions in pg_proc.dat even though they would only be used for a handful of tests in special builds. I'd agree that's not desirable. -- 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