From: | Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Set fallback_application_name for a walreceiver to cluster_name |
Date: | 2019-02-08 08:16:21 |
Message-ID: | 1257eaee-4874-e791-e83a-46720c72cac7@2ndquadrant.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
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.
Then you can do something like cluster_name = 'nodeN' and
synchronous_standby_names = 'node1,node2,node3' without any further
fiddling with application_name.
See attached patches.
I also included a patch to set cluster_name in PostgresNode.pm
instances, for easier identification and a bit of minimal testing.
Because of the issues described in [0], this doesn't allow dropping the
explicit application_name assignments in tests yet, but it's part of the
path to get there.
[0]:
<https://www.postgresql.org/message-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com>
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachment | Content-Type | Size |
---|---|---|
0001-Set-fallback_application_name-for-a-walreceiver-to-c.patch | text/plain | 3.3 KB |
0002-Set-cluster_name-for-PostgresNode.pm-instances.patch | text/plain | 1.1 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2019-02-08 08:26:46 | Re: ToDo: show size of partitioned table |
Previous Message | Tsunakawa, Takayuki | 2019-02-08 07:43:02 | RE: speeding up planning with partitions |