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
