Set fallback_application_name for a walreceiver to cluster_name
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]</messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com>, this doesn't allow dropping the
explicit application_name assignments in tests yet, but it's part of the
path to get there.
[0]: </messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com>
</messages/by-id/33383613-690e-6f1b-d5ba-4957ff40f6ce@2ndquadrant.com>
--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
Attachments:
0001-Set-fallback_application_name-for-a-walreceiver-to-c.patchtext/plain; charset=UTF-8; name=0001-Set-fallback_application_name-for-a-walreceiver-to-c.patch; x-mac-creator=0; x-mac-type=0Download+12-5
0002-Set-cluster_name-for-PostgresNode.pm-instances.patchtext/plain; charset=UTF-8; name=0002-Set-cluster_name-for-PostgresNode.pm-instances.patch; x-mac-creator=0; x-mac-type=0Download+3-2
Em sex, 8 de fev de 2019 às 05:16, Peter Eisentraut
<peter.eisentraut@2ndquadrant.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
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