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
