| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, Jacob Champion <pchampion(at)vmware(dot)com>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
| Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
| Date: | 2022-03-26 17:57:39 |
| Message-ID: | 88926.1648317459@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> 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?
Seems like making it a GUC does nothing to fix the complaint you had about
passing data to workers whether it's needed or not. Sure, we don't then
need to write any new code for it, but it's still new cycles. And it's
new cycles all throughout guc.c, too, not just in parallel worker start.
I also note that exposing it as a GUC means we have zero control over
who/what can read it. Maybe that's not a problem, but it needs to be
thought about before we go down that path.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-03-26 18:08:59 | Re: Pointer subtraction with a null pointer |
| Previous Message | Tom Lane | 2022-03-26 17:52:44 | Re: Remove an unused function GetWalRcvWriteRecPtr |