Set fallback_application_name for a walreceiver to cluster_name

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

Responses

Browse pgsql-hackers by date

  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