On Mon, Apr 26, 2021 at 6:56 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > > Stephen Frost <sfr...@snowman.net> writes: > > * Bruce Momjian (br...@momjian.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.
Thatäs why I suggested the three value one. Default to a mode where it's automatic, which is what the majority is going to want, but have a way to explicitly turn it on. > 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. Some people would. Many wouldn't, and sadly many hours would be spent on debugging things before they got there -- based on experience of how many people actually read the logs.. > 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.) The fact that we've made changes before that complicated our users experience isn't in itself an argument for doing it again though... -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
