Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points

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

In response to

Responses

Browse pgsql-hackers by date

  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