| From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
|---|---|
| To: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Set fallback_application_name for a walreceiver to cluster_name |
| Date: | 2019-02-27 10:02:18 |
| Message-ID: | 71d3a417-5607-8036-1970-8c56d61ac339@2ndquadrant.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2019-02-21 01:36, Euler Taveira wrote:
>> By default, the fallback_application_name for a physical walreceiver is
>> "walreceiver". This means that multiple standbys cannot be
>> distinguished easily on a primary, for example in pg_stat_activity or
>> synchronous_standby_names.
>>
> Although standby identification could be made by client_addr in
> pg_stat_activity, it could be useful in multiple clusters in the same
> host. Since it is a fallback application name, it can be overridden by
> an application_name in primary_conninfo parameter.
Yeah, plus that doesn't help with synchronous_standby_names.
>> I propose, if cluster_name is set, use that for
>> fallback_application_name in the walreceiver. (If it's not set, it
>> remains "walreceiver".) If someone set cluster_name to identify their
>> instance, we might as well use that by default to identify the node
>> remotely as well. It's still possible to specify another
>> application_name in primary_conninfo explicitly.
>>
> I tested it and both patches work as described. Passes all tests. Doc
> describes the proposed feature. Doc builds without errors.
Committed, thanks!
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Masahiko Sawada | 2019-02-27 10:04:33 | Re: New vacuum option to do only freezing |
| Previous Message | Heikki Linnakangas | 2019-02-27 10:00:12 | Re: Pluggable Storage - Andres's take |