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

From Nico Williams
Subject Re: GUC thread-safety approaches
Date
Msg-id aRziXkAJpdua1FCI@ubby
Whole thread Raw
In response to GUC thread-safety approaches  (Peter Eisentraut <peter@eisentraut.org>)
List pgsql-hackers
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.  Basically user-land RCU.  Or something similar to Haskell
MVars.  Or a concurrent hashmap.  Etc.  This wheel has been invented
numerous times before.

My thing is https://github.com/nicowilliams/ctp which gives you a
"thread-safe global variable" with a `get()`, `release()`, `set()` API
that gets you these semantics:

 - writes are serialized with a lock and will not wait forever for
   readers

 - reads (through a function) are fast and non-blocking

 - any value read is safe to keep using until either a) the thread
   releases it, or b) the thread reads the variable again

Values published to this should be immutable or mostly immutable (you
can mutate and access interior state with synchronized primitives, but
you can't destroy the values themselves as they are destroyed
automatically when the last reference is released).

I originally wrote this to avoid needing dreadful read-write locking
primitives to access global configuration state that changes very
occasionally.  You'd use this to protect all GUCs together rather than
one per-GUC.

The OpenSSL variant is a hazard-pointer protected concurrent hashmap,
and is in newer versions of OpenSSL.  OpenSSL used this to fix severe
threaded performance issues they had in the 3.0 release.

The OpenSSL variant would let you have high writer concurrency: N
writers can concurrently change N different keys' values in the hashmap.
This is a fantastic benefit that PG might not need.

My advice would be to adapt the OpenSSL approach (licensing issues might
force you to write your own), since it's more general than mine and has
had more eyes, but then again I've been using mine in production for a
decade.

More importantly, I think you'll want primitives and data structures
such as these for many other things besides GUCs.

Cheers,

Nico
-- 



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: GUC thread-safety approaches
Next
From: Melanie Plageman
Date:
Subject: Re: Trying out read streams in pgvector (an extension)