| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, 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> |
| Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
| Date: | 2022-03-03 07:45:33 |
| Message-ID: | YiByHbZslaZXkcqY@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Mar 02, 2022 at 01:27:40PM -0800, Andres Freund wrote:
> I don't think we should commit this without synchronizing the authn between
> worker / leader (in a separate commit). Too likely that some function that's
> marked parallel ok queries the authn_id, opening up a security/monitoring hole
> or such because of a bogus return value.
Hmm, OK. Using the same authn ID for the leader and the workers still
looks a bit strange to me as the worker is not the one that does the
authentication, only the leader does that. Anyway, FixedParallelState
includes some authentication data passed down by the leader when
spawning a worker. So, if we were to pass down the authn, we are
going to need a new PARALLEL_KEY_* to serialize and restore the data
passed down via a DSM like any other states as per the business in
parallel.c. Jacob, what do you think?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Kyotaro Horiguchi | 2022-03-03 08:04:12 | Re: shared-memory based stats collector |
| Previous Message | Daniel Westermann (DWE) | 2022-03-03 07:32:11 | Re: Changing "Hot Standby" to "hot standby" |