From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Maxim Orlov <orlovmg(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points |
Date: | 2024-08-23 03:37:59 |
Message-ID: | ZsgEF_bE0hiSAKyx@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
Attachment | Content-Type | Size |
---|---|---|
0001-Implement-workaround-to-avoid-installcheck-failure.patch | text/x-diff | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Richard Guo | 2024-08-23 03:48:37 | Re: Redundant Result node |
Previous Message | Bruce Momjian | 2024-08-23 03:33:36 | Re: Detailed release notes |