On Fri, Jul 4, 2014 at 10:33 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Vik Fearing <vik.fearing@dalibo.com> writes:
>>> You mean that if synchronous_standby_names is an empty it automatically
>>> should be set to cluster_name?
>
>> No, I mean that synchronous_standby_names should look at cluster_name
>> first, and if it's not set then unfortunately look at application_name
>> for backward compatibility.
>
> I think you're failing to explain yourself very well. What you really
> mean is that we should use cluster_name not application_name to determine
> the name that a standby server reports to the master.
>
> There's something to that, perhaps, but I think that the mechanism we use
> for doing the reporting involves the application_name parameter passed
> through libpq. It might be a bit painful to change that, and I'm not
> entirely sure it'd be less confusing.
I actually prefer it the way it is now, I think. Arguably,
application_name is not quite the right thing for identifying a
synchronous standby, because it's intended to answer the question
"What *class* of connection is this?" rather than "Which *precise*
connection is this?". But I don't think there's anything especially
wrong with having a class that has only 1 member when synchronous
replication is in use; indeed, in some ways it seems quite natural.
That connection is after all unique.
OTOH, AIUI, cluster_name is all about what shows up in the ps output,
and is intended to distinguish multiple clusters running on the same
server. If you're not doing that, you likely want cluster_name to be
empty, but you might still want to use synchronous replication. If
you are doing it, you may well want to set it to a value that
distinguishes the server only from others running on the same box,
like maybe the version number or port -- whereas for matching against
synchronous_standby_names, we need a value that's meaningful across
all related servers, but not necessarily distinguishing from other
stuff on the same server.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company