Re: GUC thread-safety approaches

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>
Cc: Peter Eisentraut <peter(at)eisentraut(dot)org>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: GUC thread-safety approaches
Date: 2025-11-18 20:52:44
Message-ID: 1320549.1763499164@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jelte Fennema-Nio <postgres(at)jeltef(dot)nl> 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 address space or not, across the board. But you could
imagine that it has no effect in sessions that have not invoked its
_PG_init function, because it hasn't been allowed to get into any
hooks. This would require that everything that _PG_init might touch
be session-local state, which might not be terribly practical. But
if we wanted to preserve the current behavior, we could make that
happen.

> 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)

I don't necessarily disagree with that. Just saying that I don't
think our hand is forced.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nico Williams 2025-11-18 21:17:18 Re: GUC thread-safety approaches
Previous Message KAZAR Ayoub 2025-11-18 20:42:39 Re: Speed up COPY FROM text/CSV parsing using SIMD