On Sat, Apr 24, 2021 at 11:54:25PM +0900, Fujii Masao wrote:
> When compute_query_id is not enabled (this is the default setting),
> pg_stat_statements doesn't track any statements. This means that
> we will see no entries in pg_stat_statements by default. I'm afraid that
> users may easily forget to enable compute_query_id
> when using pg_stat_statements (because this setting was not necessary
> in v13 or before), and finally may have noticed the mis-configuration
> and failure of statements tracking after many queries were executed.
> For example, we already have one report about this issue, in [1].
>
> Shouldn't we do something so that users can avoid such mis-configuration?
>
> One idea is to change the default value of compute_query_id from false to
> true.
> If enabling compute_query_id doesn't incur any performance penalty,
> IMO this idea is very simple and enough.
I think the query overhead was too high (2%) to enable it by default:
https://www.postgresql.org/message-id/20201016160355.GA31474@alvherre.pgsql
> Another idea is to change pg_stat_statements so that it emits an error
> at the server startup (i.e., prevents the server from starting up)
> if compute_query_id is not enabled. In this case, users can easily notice
> the mis-configuration from the error message in the server log,
> enable compute_query_id, and then restart the server.
I think it throws an error in the server logs, but preventing server
start seems extreme. Also, compute_query_id is PGC_SUSET, meaning it
can be changed by the super-user, so you could enable compute_query_id
without a server restart, which makes failing on start kind of odd.
--
Bruce Momjian <br...@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
