Re: GUC thread-safety approaches

Поиск
Список
Период
Сортировка
От Peter Eisentraut
Тема Re: GUC thread-safety approaches
Дата
Msg-id 28aea3eb-68f4-49ae-b130-743f3075666f@eisentraut.org
обсуждение исходный текст
Ответ на Re: GUC thread-safety approaches  (Heikki Linnakangas <hlinnaka@iki.fi>)
Ответы Re: GUC thread-safety approaches
Список 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 по дате отправления: