shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)
Michael Paquier <michael@paquier.xyz>
From: Michael Paquier <michael@paquier.xyz>
To: Postgres hackers <pgsql-hackers@lists.postgresql.org>
Cc: Bruce Momjian <bruce@momjian.us>, Julien Rouhaud <rjuju123@gmail.com>
Date: 2022-02-08T03:38:46Z
Lists: pgsql-hackers
Attachments
- stat-statements-fix.patch (text/x-diff) patch
Hi all, (Added Bruce and Julien in CC) 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. 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'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. The attached is enough to pass installcheck-world, on an instance where pg_stat_statements is loaded. Thoughts? -- Michael
Commits
-
Add compute_query_id = regress
- 627c79a1e87d 14.3 landed
- ebf6c5249b7d 15.0 landed