From: | Michael Paquier <michael(at)paquier(dot)xyz> |
---|---|
To: | Julien Rouhaud <rjuju123(at)gmail(dot)com> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Bruce Momjian <bruce(at)momjian(dot)us> |
Subject: | Re: shared_preload_libraries = 'pg_stat_statements' failing with installcheck (compute_query_id = auto) |
Date: | 2022-02-22 02:04:16 |
Message-ID: | YhREoCnt2VqKdUGY@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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.
Okay, thanks. I have worked on that today and applied the patch down
to 14, but without the change to enforce the parameter in the
databases created by pg_regress. Perhaps we should do that in the
long-term, but it is also possible to pass down the option to
PGOPTIONS via command line as compute_query_id is a SUSET or just set
it in postgresql.conf, and being able to do so is enough to address
all the cases I have seen and/or could think about.
--
Michael
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2022-02-22 02:45:44 | Re: pg_stat_get_replication_slot and pg_stat_get_subscription_worker incorrectly marked as proretset |
Previous Message | osumi.takamichi@fujitsu.com | 2022-02-22 01:34:25 | RE: Failed transaction statistics to measure the logical replication progress |