On Tue, May 11, 2021 at 10:51 AM Julien Rouhaud <rjuju...@gmail.com> wrote: > > On Tue, May 11, 2021 at 05:41:53PM +0900, Fujii Masao wrote: > > > > On 2021/05/11 16:35, Julien Rouhaud wrote: > > > Anyway, PFA a patch that implement a [off | on | auto] compute_query_id, > > > and > > > provides a new queryIdWanted() function to let third party plugins inform > > > us > > > that they want a query id if possible. > > > > Thanks! > > > > > > > As it was noted somewhere in that thread, that's a hack on top on the GUC > > > machinery, so compute_query_id will display "on" rather than "auto" (or > > > "auto > > > and enabled" or whatever) since GUC isn't designed to handle that > > > behavior. > > > > Can't we work around this issue by making queryIdWanted() set another flag > > like query_id_wanted instead of overwriting compute_query_id? If we do > > this, query id computation is necessary when "compute_query_id == > > COMPUTE_QUERY_ID_ON || (compute_query_id == COMPUTE_QUERY_ID_AUTO && > > query_id_wanted)". > > That's exactly what Magnus mentioned :) It's not possible because variable > aren't inherited on Windows or EXEC_BACKEND. I didn't check but I'm > assuming that it could work if the other flag was an internal GUC that > couldn't > be set by users, but then we would have some kind of internal flag that would > have to be documented as "how to check if compute_query_id" is actually > enabled > or not, which doesn't seem like a good idea.
That doesn't fundamentally make it impossible, you just have to add it to the list of variables being copied over, wouldn't you? See save_backend_variables() -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
