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.

>