On Fri, Mar 5, 2021 at 1:33 AM Álvaro Hernández <a...@ongres.com> wrote: > > > > On 5/3/21 0:21, Jacob Champion wrote: > > On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote: > >> On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchamp...@vmware.com> wrote: > >>> Idle thought I had while setting up a local test rig: Are there any > >>> compelling cases for allowing PROXY packets to arrive over Unix > >>> sockets? (By which I mean, the proxy is running on the same machine as > >>> Postgres, and connects to it using the .s.PGSQL socket file instead of > >>> TCP.) Are there cases where you want some other software to interact > >>> with the TCP stack instead of Postgres, but it'd still be nice to have > >>> the original connection information available? > >> I'm uncertain what that usecase would be for something like haproxy, > >> tbh. It can't do connection pooling, so adding it on the same machine > >> as postgres itself wouldn't really add anything, I think? > > Yeah, I wasn't thinking HAproxy so much as some unspecified software > > appliance that's performing Some Task before allowing a TCP client to > > speak to Postgres. But it'd be better to hear from someone that has an > > actual use case, instead of me spitballing. > > Here's a use case: Envoy's Postgres filter (see [1], [2]). Right now > is able to capture protocol-level metrics and send them to a metrics > collector (eg. Prometheus) while proxying the traffic. More capabilities > are being added as of today, and will eventually manage HBA too. It > would greatly benefit from this proposal, since it proxies the traffic > with, obviously, its IP, not the client's. It may be used (we do) > locally fronting Postgres, via UDS (so it can be easily trusted).
Yeah, Envoy is definitely a great example of a usecase for the proxy protocol in general. Specifically about the Unix socket though -- doesn't envoy normally run on a different instance (or in a different container at least), thus normally uses tcp between envoy and postgres? Or would it be a reasonable usecase that you ran it locally on the postgres server, having it speak IP to the clients but unix sockets to the postgres backend? I guess maybe it is outside of the containerized world? -- Magnus Hagander Me: https://www.hagander.net/ Work: https://www.redpill-linpro.com/
