| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jacob Champion <pchampion(at)vmware(dot)com> |
| Cc: | "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de> |
| Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
| Date: | 2022-04-07 00:13:32 |
| Message-ID: | Yk4srPndS0tuvJso@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Apr 06, 2022 at 07:16:43PM +0000, Jacob Champion wrote:
> I assumed that we would follow the existing model of "(de)serialize a
> whole struct", rather than pulling it apart into many separate keys. If
> it got too complicated then we could consider introducing a
> SerializedParallelProcInfo struct like some of the other functions do.
> Maybe that wouldn't work so well if many of the fields are strings?
>
> Is there a significant cost to changing this later, if one approach
> turns out to be wrong?
I don't think this is going to be an issue as long as we don't change
the definitions of MyParallelProcInfo, Port or PARALLEL_KEY_* in the
stable branch. My guess is that we are fine to switch to one approach
or the other as this is just some internal communication logic between
the parallel leader and its workers.
What is the feeling of others about this patch and the introduction of
ParallelProcInfo (or ParallelPortInfo?) to store the authn coming from
Port? The feature freeze is very close.
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2022-04-07 00:48:51 | Re: shared-memory based stats collector - v70 |
| Previous Message | David G. Johnston | 2022-04-07 00:01:17 | Re: shared-memory based stats collector - v70 |