Le jeu. 13 mai 2021 à 12:26, Kyotaro Horiguchi <horikyota....@gmail.com> a écrit :
> At Thu, 13 May 2021 12:11:12 +0900 (JST), Kyotaro Horiguchi < > horikyota....@gmail.com> wrote in > > As the result, even if we take the DLL approach, still not need to > > split out the query-id provider part. By the following config: > > > > > query_id_provider = 'pg_stat_statements' > > > > the core can obtain the entrypoint of, say, "_PG_calculate_query_id" > > to call it. And it can be of another module. > > > > It seems like the only problem doing that is we don't have a means to > > call per-process intializer for a preload libralies. > > So this is a crude PoC of that. > > pg_stat_statemnts defines its own query-id provider function in > pg_stat_statements which calls in-core DefaultJumbeQuery (end emits a > log line). > > If server started with query_id_provider='auto' and pg_stat_statements > is not loaded, pg_stat_activity.query_id is null. > > If query_id_provider='auto' and pg_stat_statements is loaded, > pg_stat_activity.query_id is filled in with a query id. > > If query_id_provider='default' or 'pg_stat_statements' and > pg_stat_statements is not loaded, pg_stat_activity.query_id is filled > in with a query id. > > If query_id_provider='none' and pg_stat_statements is loaded, it > complains as "query id provider is not available" and refuss to start. > > If showing the variable, it shows the real provider name instead of > the setting in postgresql.conf. > what if you want to have some other extensions like pg_stat_kcache or pg_store_plans that need a query_id but don't really care if pg_stat_statements is enabled or not? should they all declare their own wrapper too? should the system complain or silently ignore when they all try to install their provider function? >
