Обсуждение: 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], 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
Вложения
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