Re: [HACKERS] Client Connection redirection support for PostgreSQL - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] Client Connection redirection support for PostgreSQL
Date
Msg-id CA+Tgmobi_dLtNp8Wh39sh0ObpNZxwNwgf_=7N5Q5=-_p6BNMAg@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Client Connection redirection support for PostgreSQL  (Craig Ringer <craig@2ndquadrant.com>)
Responses RE: [HACKERS] Client Connection redirection support for PostgreSQL  (Satyanarayana Narlapuram <Satyanarayana.Narlapuram@microsoft.com>)
List pgsql-hackers
On Thu, Nov 2, 2017 at 4:33 PM, Craig Ringer <craig@2ndquadrant.com> wrote:
>> Add the ability to the PostgreSQL server instance to route the traffic to a
>> different server instance based on the rules defined in server’s pg_bha.conf
>> configuration file. At a high level this enables offloading the user
>> requests to a different server instance based on the rules defined in the
>> pg_hba.conf configuration file.
>
> pg_hba.conf is "host based access [control]" . I'm not sure it's
> really the right place.

Well, we could invent someplace else, but I'm not sure I quite see the
point (full disclosure: I suggested the idea of doing this via
pg_hba.conf in an off-list discussion).

I do think the functionality is useful, for the same reasons that HTTP
redirects are useful.  For example, let's say you have all of your
databases for various clients on a single instance.  Then, one client
starts using a lot more resources, so you want to move that client to
a separate instance on another VM.  You can set up logical replication
to replicate all of the data to the new instance, and then add a
pg_hba.conf entry to redirect connections to that database to the new
master (this would be even smoother if we had multi-master replication
in core).  So now that client is moved off to another machine in a
completely client-transparent way.  I think that's pretty cool.

> When this has come up before, one of the issues has been determining
> what exactly should constitute "read only" vs "read write" for the
> purposes of redirecting work.

Yes, that needs some thought.

> Backends used just for a redirect would be pretty expensive though.

Not as expensive as proxying the whole connection, as pgpool and other
systems do today.  I think the in-core use of this redirect
functionality is useful, but I think the real win would be optionally
using it in pgpool and pgbouncer.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Paul Ramsey
Date:
Subject: Re: [HACKERS] Parallel Plans and Cost of non-filter functions