Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)
Date
Msg-id YhAq7WxOiRLx8RaH@paquier.xyz
Whole thread Raw
In response to Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto)  (Julien Rouhaud <rjuju123@gmail.com>)
List pgsql-hackers
On Fri, Feb 18, 2022 at 05:38:56PM +0800, Julien Rouhaud wrote:
> On Fri, Feb 18, 2022 at 05:22:36PM +0900, Michael Paquier wrote:
>> So, I have been looking at this problem, and I don't see a problem in
>> doing something like the attached, where we add a "regress" mode to
>> compute_query_id that is a synonym of "auto". Or, in short, we have
>> the default of letting a module decide if a query ID can be computed
>> or not, at the exception that we hide its result in EXPLAIN outputs.
>>
>> Julien, what do you think?
>
> I don't see any problem with that patch.

Thanks for looking at it.  An advantage of this version is that it is
backpatchable as the option enum won't break any ABI compatibility, so
that's a win-win.

>> FWIW, about your question of upthread, I have noticed the behavior
>> while testing, but I know of some internal customers that enable
>> pg_stat_statements and like doing tests on the PostgreSQL instance
>> deployed this way, so that would break.  They are not on 14 yet as far
>> as I know.
>
> Are they really testing EXPLAIN output, or just doing application-level tests?

With the various internal customers, both.  And installcheck implies
EXPLAIN outputs.

First, let's wait a couple of days and see if anyone has an extra
opinion to offer on this topic.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Race conditions in 019_replslot_limit.pl
Next
From: Tom Lane
Date:
Subject: Re: Time to drop plpython2?