On Tue, 18 Nov 2025 at 09:50, Peter Eisentraut wrote:
>
> I want to discuss possible approaches to making the GUC system
> thread-safe. In particular, I want to talk about the global
> variables.
>
> A GUC parameter is defined via a struct config_generic record that
> contains some metadata and a
On 18.11.25 23:39, David Rowley wrote:
On Tue, 18 Nov 2025 at 21:50, Peter Eisentraut wrote:
where get_config_val_*() would be a thin wrapper around hash_search()
(a bit like the existing GetConfigOption() and find_option(), but
without all the error checking).
Would that be too expensive?
W
On Tue, 18 Nov 2025 at 21:50, Peter Eisentraut wrote:
> where get_config_val_*() would be a thin wrapper around hash_search()
> (a bit like the existing GetConfigOption() and find_option(), but
> without all the error checking).
>
> Would that be too expensive?
Why couldn't in-core GUCs be fields
On 18.11.25 15:15, Heikki Linnakangas wrote:
PS. I found this blog post on how Thread Local Storage is implemented on
different systems very enlightening: https://maskray.me/blog/2021-02-14-
all-about-thread-local-storage. I think whatever scheme we come up with
will be a home-grown implementat
On Tue, Nov 18, 2025 at 09:50:37AM +0100, Peter Eisentraut wrote:
> I want to discuss possible approaches to making the GUC system
> thread-safe. In particular, I want to talk about the global
> variables.
I have a thing that might work for you, and OpenSSL has a better variant
of that. Basicall
Jelte Fennema-Nio writes:
> 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.
That's not necessarily true. Certainly it will either be physically
present in the add
On Tue, Nov 18, 2025, 11:26 Peter Eisentraut 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_expla
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:
Thanks for looking into this!
On 18/11/2025 10:50, Peter Eisentraut wrote:
In Heikki's branch, the signature of this and related functions are
changed like this:
extern void DefineCustomBoolVariable(const char *name,
const char *short_desc,
I want to discuss possible approaches to making the GUC system
thread-safe. In particular, I want to talk about the global
variables.
A GUC parameter is defined via a struct config_generic record that
contains some metadata and a pointer to a global variable. For
example (simplified):
// e
10 matches
Mail list logo
