| From: | Michael Paquier <michael(at)paquier(dot)xyz> |
|---|---|
| To: | Jacob Champion <pchampion(at)vmware(dot)com> |
| Cc: | "tgl(at)sss(dot)pgh(dot)pa(dot)us" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "rjuju123(at)gmail(dot)com" <rjuju123(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, "andres(at)anarazel(dot)de" <andres(at)anarazel(dot)de>, "sfrost(at)snowman(dot)net" <sfrost(at)snowman(dot)net> |
| Subject: | Re: [PATCH] Expose port->authn_id to extensions and triggers |
| Date: | 2022-04-06 11:09:36 |
| Message-ID: | Yk108M6LazJT7Vsj@paquier.xyz |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Tue, Apr 05, 2022 at 06:23:06PM +0000, Jacob Champion wrote:
> Whether it holds meaning or not depends entirely on the auth method, I
> think. Hypothetical example -- a system could accept client
> certificates with an empty Subject. What identity that Subject
> represents would depend on the organization, but it's distinct from
> NULL/unauthenticated because the certificate is still signed by a CA.
Interesting point.
> The current patch already handles NULL with a byte of overhead; is
> there any advantage to using noError? (It might make things messier
> once a second member gets added to the struct.) My concern was directed
> at the GUC proposal.
FWIW, I am a bit concerned by this approach because it feels
inconsistent with any other conditional fields passed down from the
parallel leader to its workers. And if we need to add more fields to
ParallelProcInfo in the future, it will be cleaner to use different
TOC keys to pass down different fields anyway, no?
--
Michael
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Filip Janus | 2022-04-06 11:17:52 | Practical Timing Side Channel Attacks on Memory Compression |
| Previous Message | Ashutosh Bapat | 2022-04-06 11:00:40 | Re: How to simulate sync/async standbys being closer/farther (network distance) to primary in core postgres? |