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

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