Re: Client Connection redirection support for PostgreSQL

From: Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>
To: David Fetter <david(at)fetter(dot)org>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com>
Subject: Re: Client Connection redirection support for PostgreSQL
Date: 2017-11-03 06:31:18
Message-ID: CY1PR21MB0024588AE7B0FB659A532CE3915D0@CY1PR21MB0024.namprd21.prod.outlook.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers


> What advantages do you see in doing this in the backend over the current system where the concerns are separated, i.e. people use connection poolers like pgbouncer to do the routing?
IMHO connection pooler is not great for latency sensitive applications. For small deployments, proxy is an overhead. For example, in the cloud environment, the proxy has to sit in one data center / region and has to server the client requests serving from other data centers.

> Would it make sense also to include an optional routing algorithm or pointer to a routing function for each RoutingList, or do you see this as entirely the client's responsibility?
This is a great point, I haven't put much though into this beyond round robin / random shuffling. Providing the priority list of endpoints to the client from the server will allow client connections balanced accordingly. However, it is up to the client implementation to honor the list.

> How does this work with SSL?
The protocol doesn't change much with SSL, and after the handshake, startup message is sent to the server from the client, and the new message flow kicks on the server based on the routing list.

>> 1. Bumping the protocol version - old server instances may not understand the new client protocol
> This sounds more attractive, assuming that the feature is.
I agree, bumping the protocol version makes things simple.

> > 3. The current proposal - to keep it in the hba.conf and let the
> > server admin deal with the configuration by taking conscious
> > choice on the configuration of routing list based on the clients
>> connecting to the server instance.

>How would clients identify themselves as eligible without a protocol version bump?
Either through optional parameter, or controlled configuration by the server administrator are the only choices.
Protocol bump seems to me is a better idea here.

> So to DoS the server, what's required is a flock of old clients? I presume there's a good reason to reroute rather than serve these requests.
Possible, but I would say the server admin understands where the requests are coming from (old / new client) and does the capacity planning accordingly.

> Comments and feedback have begun.
Thank you :)

Thanks,
Satya

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Satyanarayana Narlapuram 2017-11-03 06:40:59 Re: Client Connection redirection support for PostgreSQL
Previous Message 高增琦 2017-11-03 06:20:16 Re: Try to fix endless loop in ecpg with informix mode