Re: [PATCH] Expose port->authn_id to extensions and triggers

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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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.

In response to


Browse pgsql-hackers by date

  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