Re: Adding facility for injection points (or probe points?) for more advanced tests - Mailing list pgsql-hackers

From Nathan Bossart
Subject Re: Adding facility for injection points (or probe points?) for more advanced tests
Date
Msg-id 20240104223102.GC1824373@nathanxps13
Whole thread Raw
In response to Re: Adding facility for injection points (or probe points?) for more advanced tests  (Ashutosh Bapat <ashutosh.bapat.oss@gmail.com>)
Responses Re: Adding facility for injection points (or probe points?) for more advanced tests
List 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



pgsql-hackers by date:

Previous
From: Nathan Bossart
Date:
Subject: Re: Adding facility for injection points (or probe points?) for more advanced tests
Next
From: Melanie Plageman
Date:
Subject: Re: Emit fewer vacuum records by reaping removable tuples during pruning