On Wed, Jul 2, 2014 at 3:45 AM, Vik Fearing <vik.fearing@dalibo.com> wrote:
> On 06/29/2014 02:25 PM, Andres Freund wrote:
>> On 2014-06-29 11:11:14 +0100, Thomas Munro wrote:
>>> > On 29 June 2014 10:55, Andres Freund <andres@2ndquadrant.com> wrote:
>>>> > > So, I'd looked at it with an eye towards committing it and found some
>>>> > > more things. I've now
>>>> > > * added the restriction that the cluster name can only be ASCII. It's
>>>> > > shown from several clusters with differing encodings, and it's shown
>>>> > > in process titles, so that seems wise.
>>>> > > * moved everything to the LOGGING_WHAT category
>>>> > > * added minimal documention to monitoring.sgml
>>>> > > * expanded the config.sgml entry to mention the restriction on the name.
>>>> > > * Changed the GUCs short description
>>> >
>>> > Thank you.
>>> >
>>>> > > I also think, but haven't done so, we should add a double colon after
>>>> > > the cluster name, so it's not:
>>>> > >
>>>> > > postgres: server1 stats collector process
>>>> > > but
>>>> > > postgres: server1: stats collector process
>>> >
>>> > +1
>>
>> Committed with the above changes. Thanks for the contribution!
>
> Is there a reason for not using this in synchronous_standby_names,
> perhaps falling back to application_name if not set?
You mean that if synchronous_standby_names is an empty it automatically
should be set to cluster_name? Or, you mean that if application_name is not
set in primary_conninfo the standby should automatically use its cluster_name
as application_name in primary_conninfo? I'm afraid that those may cause
the trouble such as that standby is unexpectedly treated as synchronous one
even though a user want to set up it as asynchronous one by emptying
synchronous_standby_names in the master.
Regards,
--
Fujii Masao
