| From: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
|---|---|
| To: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Set fallback_application_name for a walreceiver to cluster_name |
| Date: | 2019-02-21 00:36:06 |
| Message-ID: | CAHE3wggnEhDYbG3MVgpr3_28KMhFjqi3nFwK1RzT5-q4yN5AbQ@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Em sex, 8 de fev de 2019 às 05:16, Peter Eisentraut
<peter(dot)eisentraut(at)2ndquadrant(dot)com> escreveu:
>
> 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.
> 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.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2019-02-21 00:37:18 | Re: propagating replica identity to partitions |
| Previous Message | Stephen Frost | 2019-02-21 00:20:15 | Re: WAL insert delay settings |