Hi,
On 2022-03-26 15:18:59 +0900, Michael Paquier wrote:
> On Thu, Mar 24, 2022 at 05:44:06PM +0000, Jacob Champion wrote:
> > On Wed, 2022-03-23 at 16:54 -0700, Andres Freund wrote:
> >> Another option would be to make it a GUC. With a bit of care it could be
> >> automatically synced by the existing parallelism infrastructure...
> >
> > Like a write-once, PGC_INTERNAL setting?
Perhaps PGC_INTERNAL, perhaps PGC_SU_BACKEND, set with PGC_S_OVERRIDE?
> > I guess I don't have any
> > intuition on how that would compare to the separate-global-and-accessor
> > approach. Is the primary advantage that you don't have to maintain the
> > serialization logic, or is there more to it?
>
> Hmm. That would be a first for a GUC, no? It is not seem natural
> compared to the other information pieces passed down from the leader
> to the workers.
What would be the first for a GUC? We have plenty GUCs that are set on a
per-connection basis to reflect some fact? And there's several authenitcation
related bits of state known to guc.c , think role, session_authorization,
is_superuser.
Sharing per-connection state via GUCs for paralellism? I don't think that is
true either. E.g. application_name, client_encoding.
> +extern SharedPort MyProcShared;
I strongly dislike MyProcShared. It's way too easily confused with MyProc
which point to shared memory.
Greetings,
Andres Freund
