Re: GUC thread-safety approaches - Mailing list pgsql-hackers

From Peter Eisentraut
Subject Re: GUC thread-safety approaches
Date
Msg-id 28aea3eb-68f4-49ae-b130-743f3075666f@eisentraut.org
Whole thread Raw
In response to Re: GUC thread-safety approaches  (Heikki Linnakangas <hlinnaka@iki.fi>)
Responses Re: GUC thread-safety approaches
List pgsql-hackers
On 18.11.25 15:15, Heikki Linnakangas wrote:
> Instead of a hash table to hold the values, you could have a dynamically 
> extendable "struct". DefineCustomXXXVariable can reserve an offset and 
> store it in a global variable. So the code to read the current GUC value 
> would look something like this:
> 
> /* defined elsewhere */
> struct Session {
>      ...
>      /* this area holds all the GUC values for the current session */
>      char *guc_values;
> }
> 
> _Thread_local struct Session *session;
> 
> /* global variable set by DefineCustomBooleanVariable */
> size_t enable_seqscan_offset;

The way I understand this, this would only work if 
DefineCustomXXXVariable could only be called from a global context 
(e.g., shared_preload_libraries).  But AFAICT, you can define custom GUC 
parameters per session (e.g., LOAD 'auto_explain'), and so each session 
would have a different offset, and so the offset variable would itself 
have to be session-local.




pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [PATCH] Allow complex data for GUC extra.
Next
From: Tomas Vondra
Date:
Subject: Re: Performance issues with parallelism and LIMIT