Re: GUC thread-safety approaches
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
To: Peter Eisentraut <peter@eisentraut.org>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2025-11-18T20:37:43Z
Lists: 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. >