Re: Making server name part of the startup message

> I should think that in such cases, the end client is exactly not what you want to be choosing which server it gets redirected to. You'd be wanting to base that on >policies defined at the pooler. There are already plenty of client-supplied attributes 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 need to include the server name in it, and for proxy it is optional to include this field while sending the startup message to the server. It is preferred to set the field for the Azure PostgreSQL service instead of appending the cluster name 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 will not be included otherwise.

Thanks,
Satya

-----Original Message-----
From: Tom Lane [mailto:tgl(at)sss(dot)pgh(dot)pa(dot)us]
Sent: Thursday, June 15, 2017 8:58 AM
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Satyanarayana Narlapuram <Satyanarayana(dot)Narlapuram(at)microsoft(dot)com>; pgsql-hackers(at)postgresql(dot)org
Subject: Re: [HACKERS] Making server name part of the startup message

Alvaro Herrera <alvherre(at)2ndquadrant(dot)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 redirected to. You'd be wanting to base that on policies defined at the pooler. There are already plenty of client-supplied attributes 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