From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Lev Kokotov <lev(at)hyperparam(dot)ai>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Add "host" to startup packet |
Date: | 2023-04-02 16:21:41 |
Message-ID: | CAM-w4HNVC+HQ9kG0SWGFXUiiNe-qT7atY-aWxJqV07su_jOPGw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, 2 Apr 2023 at 11:38, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>
> Even if all that infrastructure sprang into existence, is this really any
> more useful than basing your switching on the host's resolved IP address?
> I'm doubtful that there's enough win there to justify pushing this rock
> to the top of the mountain.
Hm. I think it's going to turn out to be useful. Experience shows
depending on the ip address often paints people into corners. However
I agree that we need to actually have a real use case in hand where
someone is going to actually do something with it.
My question is a bit different. How does this interact with TLS SNI.
Can you just use the SNI name given in the TLS handshake? Should the
server require them to match? Is there any value to having a separate
source for this info? Is something similar available in GSSAPI
authentication?
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-04-02 16:24:34 | Re: regression coverage gaps for gist and hash indexes |
Previous Message | Tom Lane | 2023-04-02 15:38:25 | Re: Add "host" to startup packet |