| 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.
| 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. |