Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Alvaro Herrera <alvherre@alvh.no-ip.org>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Maxim Orlov <orlovmg@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2024-08-23T03:37:59Z
Lists: pgsql-hackers
Attachments
- 0001-Implement-workaround-to-avoid-installcheck-failure.patch (text/x-diff) patch 0001
On Tue, Aug 20, 2024 at 12:30:35PM -0400, Alvaro Herrera wrote: > Yeah, I like this option. Injection points require to be explicitly > enabled in configure, so skipping that test when injection_points can't > be found seems reasonable. My apologies for the delay in doing something here. The simplest thing would be to scan pg_available_extensions after the first node is started, like in the attached. What do you think? > This also suggests that EXTRA_INSTALL should have injection_points only > when the option is enabled. If the switch is disabled, the path is just ignored, so I don't see any harm in keeping it listed all the time. > I've been curious about what exactly does this Makefile line > export enable_injection_points enable_injection_points > achieve. Without this line, the TAP tests would not be able to know if injection points are enabled or not, no? Well, it is true that we could also do something like a scan of pg_config.h in the installation path, but this is consistent with what ./configure uses. -- Michael
Commits
-
Check availability of module injection_points in TAP tests
- 5735521ac2d5 18.0 landed
-
Avoid installcheck failure in TAP tests using injection_points
- bab1fd9277c2 17.0 landed
- 2cdcae9da696 18.0 landed
-
Simplify makefiles exporting twice enable_injection_points
- ff43b5e70d45 17.0 landed
- 516ff05539bb 18.0 landed