On Fri, Jul 4, 2014 at 10:33 AM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Vik Fearing <vik.fear...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
