Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)

Hi,

On Tue, Feb 08, 2022 at 12:38:46PM +0900, Michael Paquier wrote:
>
> While testing installcheck with various server configurations to see
> how the main regression test suites could break, I found that loading
> pg_stat_statements into the backend is enough to break installcheck
> as compute_query_id = auto, the default, lets the decision to compute
> query IDs to pg_stat_statements itself. In short, loading
> pg_stat_statements breaks EXPLAIN outputs of any SQL-based regression
> test.

Indeed, that's unfortunate but that's also a known behavior.

> Running installcheck on existing installations is a popular sanity
> check, as much as is enabling pg_stat_statements by default, so it
> seems to me that we'd better disable compute_query_id by default in
> the databases created for the sake of the regression tests, enabling
> it only in places where it is relevant. We do that in explain.sql for
> a test with compute_query_id, but pg_stat_statements does not do
> that.

I agree that enabling pg_stat_statements is something common when you're
actually going to use your instance, I'm not sure that it also applies to
environment for running regression tests.

> I'd like to suggest a fix for that, by tweaking the tests of
> pg_stat_statements to use compute_query_id = auto, so as we would
> still stress the code paths where the module takes the decision to
> compute query IDs, while the default regression databases would
> disable it. Please note that this also fixes the case of any
> out-of-core modules that have EXPLAIN cases.

That's already been discussed in [1] and rejected, as it would also mean losing
the ability to have pg_stat_statements (or any similar extension) coverage
using the regression tests. I personally rely on regression tests for such
custom extensions quite a lot, so I'm still -1 on that.

[1] https://www.postgresql.org/message-id/flat/1634283396.372373993%40f75.i.mail.ru