Re: [PATCH] Expose port->authn_id to extensions and triggers
Jacob Champion <pchampion@vmware.com>
From: Jacob Champion <pchampion@vmware.com>
To: "tgl@sss.pgh.pa.us" <tgl@sss.pgh.pa.us>
Cc: "sfrost@snowman.net" <sfrost@snowman.net>, "rjuju123@gmail.com" <rjuju123@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>, "michael@paquier.xyz" <michael@paquier.xyz>, "andres@anarazel.de" <andres@anarazel.de>
Date: 2022-03-23T22:52:22Z
Lists: pgsql-hackers
Attachments
- v6-0001-Add-API-to-retrieve-authn_id-from-SQL.patch (text/x-patch) patch v6-0001
- v6-0002-Allow-parallel-workers-to-use-pg_session_authn_id.patch (text/x-patch) patch v6-0002
On Thu, 2022-03-17 at 18:33 -0400, Tom Lane wrote: > Yeah. It seems to me that putting the auth info into struct Port was > a fairly random thing to do in the first place, and we are now dealing > with the fallout of that. > > I think what we ought to do here is separate out the data that we think > parallel workers need access to. It does not seem wise to say "workers > can access fields A,B,C of MyPort but not fields X,Y,Z". I do not have > a concrete proposal for fixing it though. v6-0002 has my first attempt at this. I moved authn_id into its own substruct inside Port, which gets serialized with the parallel key machinery. (My name selection of "SharedPort" is pretty bland.) Over time, we could move more fields into the shared struct and fill out the serialization logic as needed, and then maybe eventually SharedPort can be broken off into its own thing with its own allocation. But I don't know if we should do it all at once, yet. WDYT? --Jacob
Commits
-
Remove initialization of MyClientConnectionInfo at backend startup
- 701ac2cb1fa2 16.0 landed
-
Allow parallel workers to retrieve some data from Port
- d951052a9e02 16.0 landed