> I should think that in such cases, the end client is exactly not what you want to be choosing which server it gets
redirectedto. You'd be wanting to base that on >policies defined at the pooler. There are already plenty of
client-suppliedattributes you could use as inputs for such policies (user name and application name, for >instance).
Pooler would be the end client for the Postgres database cluster, and connection string changes are required at the
pooler.There is no change in the connection string format in such cases.
>Why do we need to incur a protocol break to add another one?
This is optional and is not a protocol break. This doesn't make the cluster name field mandatory in the startup
message.If the client specifies the extra parameter in the connection string to include the server name in the startup
message,then only it will be included otherwise it is not. In a proxy scenario, end client's startup message doesn't
needto include the server name in it, and for proxy it is optional to include this field while sending the startup
messageto the server. It is preferred to set the field for the Azure PostgreSQL service instead of appending the
clustername to the user name.
Proposed LibPQ connection string format would be:
host=localhost port=5432 dbname=mydb connect_timeout=10 include_cluster_name=true
include_cluster_name is an optional parameter and setting this true includes cluster_name in the startup message and
willnot be included otherwise.
Thanks,
Satya
-----Original Message-----
From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
Sent: Thursday, June 15, 2017 8:58 AM
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Satyanarayana Narlapuram <Satyanarayana.Narlapuram@microsoft.com>; pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Making server name part of the startup message
Alvaro Herrera <alvherre@2ndquadrant.com> writes:
> Tom Lane wrote:
>> This makes no sense at all. The client is telling the server what
>> the server's name is?
> I think for instance you could have one pgbouncer instance (or
> whatever
> pooler) pointing to several different servers. So the client connects
> to the pooler and indicates which of the servers to connect to.
I should think that in such cases, the end client is exactly not what you want to be choosing which server it gets
redirectedto. You'd be wanting to base that on policies defined at the pooler. There are already plenty of
client-suppliedattributes you could use as inputs for such policies (user name and application name, for instance).
Why do we need to incur a protocol break to add another one?
regards, tom lane