> 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.
Advertising
>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:t...@sss.pgh.pa.us]
Sent: Thursday, June 15, 2017 8:58 AM
To: Alvaro Herrera <alvhe...@2ndquadrant.com>
Cc: Satyanarayana Narlapuram <satyanarayana.narlapu...@microsoft.com>;
pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Making server name part of the startup message
Alvaro Herrera <alvhe...@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 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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers