On Sun, Apr 25, 2021 at 01:17:03PM -0400, Tom Lane wrote: > Julien Rouhaud <rjuju...@gmail.com> writes: > > On Sun, Apr 25, 2021 at 11:39:55AM -0400, Tom Lane wrote: > >> I agree repeated warnings would be bad news. I was wondering if we could > >> arrange a single warning at the time pg_stat_statements is preloaded into > >> the postmaster. In this way, if you tried to use a configuration file > >> that used to work, you'd hopefully get some notice about why it no longer > >> does what you want. Also, if you are preloading pg_stat_statements, it > >> seems reasonable to assume that you'd like the global value of the flag > >> to be "on", even if there are use-cases for transiently disabling it. > > > What about people who wants to use pg_stat_statements but are not ok with > > our > > query_id heuristics and use a third-party plugin for that? > > They're still going to want the GUC set to something other than "off", > no?
They will want compute_query_id to be off. And they actually will *need* that, as we recommend third-party plugins computing alternative query_id to error out if they see a that a query_id has already been generated, to avoid any problem if compute_query_id is being temporarily toggled. That's what I did in the POC plugin for external query_id at [1]. > In any case it's just a one-time log message, so it's not likely > to be *that* annoying. In that case it should be phrased in a way that makes it clear that pg_stat_statements can work without enabling compute_query_id, something like: "compute_query_id is disabled. This module won't track any activity unless you configured a third-party extension that computes query identifiers" [1] https://github.com/rjuju/pg_queryid/blob/master/pg_queryid.c#L172
