Horton

Re: Adding facility for injection points (or probe points?) for more advanced tests

Michael Paquier <michael@paquier.xyz>

View thread View on postgr.es
From: Michael Paquier <michael@paquier.xyz>
To: Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>
Cc: Nathan Bossart <nathandbossart@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Postgres hackers <pgsql-hackers@lists.postgresql.org>
Date: 2024-01-05T07:18:49Z
Lists: pgsql-hackers 
On Fri, Jan 05, 2024 at 12:41:33PM +0530, Ashutosh Bapat wrote:
> Well, you have already showed that the SQL interface created for the
> test module is being used for testing a core feature. The tests for
> that should stay somewhere near the other tests for those features.
> Using an extension named "test_injection_point" and which resides in a
> test module for testing core features doesn't look great. Hence
> suggestion to move it to contrib.

I mean why?  We test a bunch of stuff in src/test/modules/, and this
is not intended to be released to the outside world.

Putting that in contrib/ has a lot of extra cost.  One is
documentation and more complexity regarding versioning when it comes
to upgrading it to a new version.  I don't think that it is a good
idea to deal with this extra load of work for something that I'd aim
to be used for having improved *test* coverage, and the build switch
should stay.  Saying that, I'd be OK with renaming the module to
injection_points, but I will fight hard about keeping that in
src/test/modules/.  That's less maintenance headache to think about
when having to deal with complex racy bugs.
--
Michael

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