From: | Jacob Champion <pchampion(at)vmware(dot)com> |
---|---|
To: | "magnus(at)hagander(dot)net" <magnus(at)hagander(dot)net> |
Cc: | "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: PROXY protocol support |
Date: | 2021-03-04 23:21:14 |
Message-ID: | d3a8e38c7a1c39034cbce45730456587b65479b1.camel@vmware.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, 2021-03-04 at 21:45 +0100, Magnus Hagander wrote:
> On Thu, Mar 4, 2021 at 9:07 PM Jacob Champion <pchampion(at)vmware(dot)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.
> Iid think about the other end, if you had a proxy on a different
> machine accepting unix connections and passing them on over
> PROXY-over-tcp. But I doubt it's useful to know it was unix in that
> case (since it still couldn't do peer or such for the auth) --
> instead, that seems like an argument where it'd be better to proxy
> without using PROXY and just letting the IP address be.
You could potentially design a system that lets you proxy a "local all
all trust" setup from a different (trusted) machine, without having to
actually let people onto the machine that's running Postgres. That
would require some additional authentication on the PROXY connection
(i.e. something stronger than host-based auth) to actually be useful.
-- other notes --
A small nitpick on the current separate-port PoC is that I'm forced to
set up a "regular" TCP port, even if I only want the PROXY behavior.
The original-host logging isn't working for me:
WARNING: pg_getnameinfo_all() failed: ai_family not supported
LOG: proxy connection from: host=??? port=???
and I think the culprit is this:
> /* Store a copy of the original address, for logging */
> memcpy(&raddr_save, &port->raddr, port->raddr.salen);
port->raddr.salen is the length of port->raddr.addr; we want the length
of the copy to be sizeof(port->raddr) here, no?
--Jacob
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Nancarrow | 2021-03-04 23:37:29 | Re: Parallel INSERT (INTO ... SELECT ...) |
Previous Message | Thomas Munro | 2021-03-04 23:12:36 | Re: Replace buffer I/O locks with condition variables (reviving an old patch) |