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

On Tue, Feb 08, 2022 at 12:56:59PM +0900, Michael Paquier wrote:
> On Tue, Feb 08, 2022 at 11:48:15AM +0800, Julien Rouhaud wrote:
> > 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.
>
> Well, I can see that this is a second independent complain after a few
> months.

> If you wish to keep this capability, wouldn't it be better to
> add a "regress" mode to compute_query_id, where we would mask
> automatically this information in the output of EXPLAIN but still run
> the computation?

Did you just realize you had some script broken because of that (or have an
actual need) or did you only try to see what setting breaks the regression
tests? If the latter, it seems that the complaint seems a bit artificial.

No one complained about it since, and I'm assuming that pgpro could easily fix
their test workflow since they didn't try to do add such a new mode.

I suggested something like that in the thread but Tom didn't seemed
interested. Note that it would be much cleaner to do now that we rely on an
internal query_id_enabled variable rather than changing compute_query_id value,
but I don't know if it's really worth the effort given the number of things
that already breaks the regression tests.