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

From Jelte Fennema-Nio
Subject Re: GUC thread-safety approaches
Date
Msg-id CAGECzQTuFaMcCPbQQQ9JDpkESkkHB==cvWVNzHR+vK6JLPwAFg@mail.gmail.com
Whole thread Raw
In response to Re: GUC thread-safety approaches  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: GUC thread-safety approaches
List pgsql-hackers
On Tue, Nov 18, 2025, 11:26 Peter Eisentraut <peter@eisentraut.org> wrote:
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.

I think that a session-local LOAD is something we're going to lose with threading anyway. A shared library is only going to be loaded once for the cluster, not once per backend. And to be clear: I think that's totally fine. (i.e. the benefit of these session-local extensions seems to small for us to find and maintain some workaround for this) 

So having a DefineCustomXXXVariable only be callable from a global context seems fine to me. 

I quite like the idea of this global offset array btw. 

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: POC: enable logical decoding when wal_level = 'replica' without a server restart
Next
From: KAZAR Ayoub
Date:
Subject: Re: Speed up COPY FROM text/CSV parsing using SIMD