SR/libpq - outbound interface/ipaddress binding

While playing with SR/HS in a more complex datacenter environment I
immediatly hit the need to being able to specify the ipaddress(or
interface) that the backend(or libpq) uses to connect to the master.

There are a few reasons for being able to do so like:

* we are now suddenly in a situation where the backend can create
outbound connections on it's own so people will have to add firewall
rules and being able to guarantee the source IP will help maintainance
(otherwise stuff might break if you say add an alias IP on an interface)
* prioritising - if you know that replication traffic is on a given IP
you can actually do fancy stuff like routing it over a different gigE
line or giving it prority on a WAN connection
* some of those also apply to other libpq clients but those are usually
not in that complex network/system environments as servers are

comment?

Stefan

2010/2/23 Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>:
> While playing with SR/HS in a more complex datacenter environment I immediatly hit the need to being able to specify the ipaddress(or interface) that the backend(or libpq) uses to connect to the master.
>
> There are a few reasons for being able to do so like:
>
> * we are now suddenly in a situation where the backend can create outbound connections on it's own so people will have to add firewall rules and being able to guarantee the source IP will help maintainance (otherwise stuff might break if you say add an alias IP on an interface)
> * prioritising - if you know that replication traffic is on a given IP you can actually do fancy stuff like routing it over a different gigE line or giving it prority on a WAN connection
> * some of those also apply to other libpq clients but those are usually not in that complex network/system environments as servers are
>
>
> comment?

Seems like this could be very useful functionality, provided it can be
done in a reasonably portable way. As long as it's a libpq connection
parameter, it'll benefit everybody else as well as the replication
stuff at no extra cost.

It's not a very broad use-case, but in that use-case I can see how it
would be very useful.

Now, are you up for actually writing it? ;)

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On Tue, 2010-02-23 at 10:00 +0100, Stefan Kaltenbrunner wrote:
> While playing with SR/HS in a more complex datacenter environment I
> immediatly hit the need to being able to specify the ipaddress(or
> interface) that the backend(or libpq) uses to connect to the master.
>
> There are a few reasons for being able to do so like:
>
> * we are now suddenly in a situation where the backend can create
> outbound connections on it's own so people will have to add firewall
> rules and being able to guarantee the source IP will help maintainance
> (otherwise stuff might break if you say add an alias IP on an interface)
> * prioritising - if you know that replication traffic is on a given IP
> you can actually do fancy stuff like routing it over a different gigE
> line or giving it prority on a WAN connection
> * some of those also apply to other libpq clients but those are usually
> not in that complex network/system environments as servers are

The whole reason for using libpq was that it gave us a stable base to
work on. It also means that we are restricted to any issues libpq has,
though the benefit is that any improvement there helps all clients. So
any changes you make would benefit Slony, Bucardo, Londiste as well.

Not for 9.0, though sounds like a welcome change.

--
Simon Riggs www.2ndQuadrant.com

Simon Riggs wrote:
> On Tue, 2010-02-23 at 10:00 +0100, Stefan Kaltenbrunner wrote:
>> While playing with SR/HS in a more complex datacenter environment I
>> immediatly hit the need to being able to specify the ipaddress(or
>> interface) that the backend(or libpq) uses to connect to the master.
>>
>> There are a few reasons for being able to do so like:
>>
>> * we are now suddenly in a situation where the backend can create
>> outbound connections on it's own so people will have to add firewall
>> rules and being able to guarantee the source IP will help maintainance
>> (otherwise stuff might break if you say add an alias IP on an interface)
>> * prioritising - if you know that replication traffic is on a given IP
>> you can actually do fancy stuff like routing it over a different gigE
>> line or giving it prority on a WAN connection
>> * some of those also apply to other libpq clients but those are usually
>> not in that complex network/system environments as servers are
>
> The whole reason for using libpq was that it gave us a stable base to
> work on. It also means that we are restricted to any issues libpq has,
> though the benefit is that any improvement there helps all clients. So
> any changes you make would benefit Slony, Bucardo, Londiste as well.

or rather any libpq client that wants to have some control over the
outbound interface...

>
> Not for 9.0, though sounds like a welcome change.

yeah - any objections if I add it to the TODO for now?

Stefan

Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc> writes:
> Simon Riggs wrote:
>> Not for 9.0, though sounds like a welcome change.

> yeah - any objections if I add it to the TODO for now?

None, it seems like a reasonable future feature.

regards, tom lane