| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Bruce Momjian <bruce(at)momjian(dot)us>, Christoph Berg <myon(at)debian(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Magnus Hagander <magnus(at)hagander(dot)net>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: compute_query_id and pg_stat_statements |
| Date: | 2021-04-26 16:56:13 |
| Message-ID: | 2267128.1619456173@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Stephen Frost <sfrost(at)snowman(dot)net> writes:
> * Bruce Momjian (bruce(at)momjian(dot)us) wrote:
>> Techically, pg_stat_statements can turn on compute_query_id when it is
>> loaded, even if it is 'off' in postgresql.conf, right? And
>> pg_stat_statements would know if an alternate hash method is being used,
>> right?
> +1 on this approach.
That'd make it impossible to turn off or adjust afterwards, wouldn't it?
I'm afraid the confusion stemming from that would outweigh any simplicity.
I would be in favor of logging a message at startup to the effect of
"this is misconfigured" (as per upthread discussion), although whether
people would see that is uncertain.
In the end, it's not like this is the first time we've ever made an
incompatible change in configuration needs; and it won't be the last
either. I don't buy the argument that pg_stat_statements users can't
cope with adding the additional setting. (Of course, we should be
careful to call it out as an incompatible change in the release notes.)
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavel Stehule | 2021-04-26 16:57:17 | ERROR: relation "sql_features" does not exist |
| Previous Message | Dean Rasheed | 2021-04-26 16:42:28 | Re: Does rewriteTargetListIU still need to add UPDATE tlist entries? |