Обсуждение: installcheck fails when compute_query_id=on or pg_stat_statsement is loaded
installcheck fails when compute_query_id=on or pg_stat_statsement is loaded
От
Мельников Антон Андреевич
Дата:
Hello!
When extension pg_stat_statsement is loaded into memory or compute_query_id=on in postgesql.conf
many of installcheck tests give errors.
The thing is that in *.out files appear lines "queryid = xxxxx" where xxxxx - some numeric value.
So 24 of 209 installcheck tests will fail.
The thing is that in *.out files appear lines "queryid = xxxxx" where xxxxx - some numeric value.
So 24 of 209 installcheck tests will fail.
It seems to be a normal behaviour as queryid calculation was moved into core in
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5fd9dfa5f5
but tests say that something wrong.
Create test variants is not the way, as queryid value varies randomly
from test to test at the same enviroment.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=5fd9dfa5f5
but tests say that something wrong.
Create test variants is not the way, as queryid value varies randomly
from test to test at the same enviroment.
I think this is a problem because these fake errors can mask a real errors in relevant tests.
What’s your opinion?
What’s your opinion?
Best regards,
Anton Melnikov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Re: installcheck fails when compute_query_id=on or pg_stat_statsement is loaded
От
Julien Rouhaud
Дата:
On Fri, Oct 15, 2021 at 3:36 PM Мельников Антон Андреевич <aamelnikov@inbox.ru> wrote: > > When extension pg_stat_statsement is loaded into memory or compute_query_id=on in postgesql.conf > many of installcheck tests give errors. > [...] > I think this is a problem because these fake errors can mask a real errors in relevant tests. > What’s your opinion? This has been discussed previously (although I can't find the thread right now). Note that you don't really need to enable pg_stat_statements, enabling compute_query_id is enough. The query identifier is only displayed for EXPLAIN (VERBOSE), so it's already a bit filtered. I don't see any simple way to entirely avoid the problem though. There are already many options that can break the regression tests, so maybe it's ok to accept that this is yet another one. If not, the only alternative I see is to add a boolean QUERY_ID option to EXPLAIN and make sure that all tests use it, but it seems like a big hammer, error prone, for a maybe small problem.
Julien Rouhaud <rjuju123@gmail.com> writes: > ... Note that you don't really need to enable > pg_stat_statements, enabling compute_query_id is enough. The query > identifier is only displayed for EXPLAIN (VERBOSE), so it's already a > bit filtered. I don't see any simple way to entirely avoid the > problem though. > There are already many options that can break the regression tests, so > maybe it's ok to accept that this is yet another one. Yeah, that's my reaction. We could add "compute_query_id = off" to the database-level settings set up by pg_regress, but that cure seems worse than the disease. It would make it impossible to run the regression tests with pg_stat_statements loaded, which you might wish to do (just ignoring the bogus test failures) as a way of testing pg_stat_statements. regards, tom lane