From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Мельников Антон Андреевич <aamelnikov(at)inbox(dot)ru>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: installcheck fails when compute_query_id=on or pg_stat_statsement is loaded |
Date: | 2021-10-15 13:46:18 |
Message-ID: | 952792.1634305578@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Julien Rouhaud <rjuju123(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-10-15 14:07:21 | Re: Unbounded %s in sscanf |
Previous Message | Dave Cramer | 2021-10-15 13:39:36 | Re: [PATCH] Proposal for HIDDEN/INVISIBLE column |