public inbox for [email protected]
help / color / mirror / Atom feedFrom: Michael Paquier <[email protected]>
To: Maxim Orlov <[email protected]>
Cc: Tom Lane <[email protected]>
Cc: Alvaro Herrera <[email protected]>
Cc: pgsql-hackers <[email protected]>
Subject: Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points
Date: Thu, 5 Sep 2024 10:59:13 +0900
Message-ID: <[email protected]> (raw)
In-Reply-To: <CACG=eza1Z_FG-ZgNRieK6gHoxghBymezqcHJkdOWdxALbLWSVA@mail.gmail.com>
References: <[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<CACG=eza1Z_FG-ZgNRieK6gHoxghBymezqcHJkdOWdxALbLWSVA@mail.gmail.com>
On Wed, Sep 04, 2024 at 07:05:32PM +0300, Maxim Orlov wrote:
> Works for me with configure build. Meson build, obviously, still need extra
> "meson compile install-test-files" step
> as expected. From your patch, I see that you used safe_psql call to check
> for availability of the injection_points
> extension.
> Are there some hidden, non-obvious reasons for it? It's much
> simpler to check output of the
> pg_config as Álvaro suggested above, does it? And we don't need active node
> for this. Or I miss something?
Even if the code is compiled with injection points enabled, it's still
going to be necessary to check if the module exists in the
installation or not. And it may or may not be around.
One thing that we could do, rather than relying on the environment
variable for the compile-time check, would be to scan pg_config.h for
"USE_INJECTION_POINTS 1". If it is set, we could skip the use of these
environment variables. That's really kind of the same thing for
with_ssl or similar depending on the dependencies that exist. So
that's switching one thing to the other. I am not sure that's worth
switching at this stage. It does not change the need of a runtime
check to make sure that the module is installed, though.
Another thing that we could do, rather than query
pg_available_extension, is implementing an equivalent on the perl
side, scanning an installation tree for a module .so or equivalent,
but I've never been much a fan of the extra maintenance burden these
duplications introduce, copying what the backend is able to handle
already in a more transparent way for the TAP routines.
> And one other thing I must mention. I don't know why, but my pg_config from
> meson build show empty configure
> despite the fact, I make pass the same options in both cases.
>
> autotools:
> $ ./pg_config --configure
> '--enable-debug' '--enable-tap-tests' '--enable-depend' ....
>
> meson:
> $ ./pg_config --configure
Yes, ./configure does not apply to meson, so I'm not sure what we
should do here, except perhaps inventing a new option switch that
reports the options that have been used with the meson command, or
something like that.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (833B, ../[email protected]/2-signature.asc)
download
view thread (3+ messages)
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected]
Subject: Re: Test 041_checkpoint_at_promote.pl faild in installcheck due to missing injection_points
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox