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

  1. ci: Enable injection points in builds

  2. Fix two memcpy() bugs in the new injection point code

  3. Add test module injection_points

  4. Add backend support for injection points

  5. Refactor code checking for file existence