Re: GUC thread-safety approaches

From: Peter Eisentraut <peter(at)eisentraut(dot)org>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUC thread-safety approaches
Date: 2025-11-18 17:26:33
Message-ID: 28aea3eb-68f4-49ae-b130-743f3075666f@eisentraut.org
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tomas Vondra 2025-11-18 17:31:24 Re: Performance issues with parallelism and LIMIT
Previous Message Robert Haas 2025-11-18 17:24:50 Re: [PATCH] Allow complex data for GUC extra.