> 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.
Forexample, in the cloud environment, the proxy has to sit in one data center / region and has to server the client
requestsserving 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
prioritylist of endpoints to the client from the server will allow client connections balanced accordingly. However, it
isup 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
thanserve these requests.
Possible, but I would say the server admin understands where the requests are coming from (old / new client) and does
thecapacity planning accordingly.
> Comments and feedback have begun.
Thank you :)
Thanks,
Satya
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers