Re: GUC thread-safety approaches

From: Nico Williams <nico(at)cryptonector(dot)com>
To: Peter Eisentraut <peter(at)eisentraut(dot)org>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUC thread-safety approaches
Date: 2025-11-18 21:17:18
Message-ID: aRziXkAJpdua1FCI@ubby
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: 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
--

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Melanie Plageman 2025-11-18 21:17:28 Re: Trying out read streams in pgvector (an extension)
Previous Message Tom Lane 2025-11-18 20:52:44 Re: GUC thread-safety approaches