BUG #16288: application_name from client's primary_conninfo not set in pg_stat_replication on master
От | PG Bug reporting form |
---|---|
Тема | BUG #16288: application_name from client's primary_conninfo not set in pg_stat_replication on master |
Дата | |
Msg-id | 16288-67b2b6ad2d4178c6@postgresql.org обсуждение исходный текст |
Ответы |
Re: BUG #16288: application_name from client's primary_conninfo not set in pg_stat_replication on master
|
Список | pgsql-bugs |
The following bug has been logged on the website: Bug reference: 16288 Logged by: Andreas Ntaflos Email address: daff@ptmx.at PostgreSQL version: 12.2 Operating system: Ubuntu 18.04 Description: In a two-node PostgreSQL 12.2 replication scenario, where one node is master and the other a streaming client, the application_name field in the client's primary_conninfo setting does not appear to be set correctly in the pg_stat_replication view on the master. Instead of the application_name value defined on the client side, the pg_stat_replication view shows the cluster name in the application_name column. In our case the replication scenario is managed by Corosync/Pacemaker and the pgsql resource agent (latest from https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/pgsql which supports the replication/recovery changes introduced in PostgreSQL 12). This currently doesn't work correctly since the resource agent relies on the information queried from pg_stat_replication to match the Pacemaker cluster configuration settings, where application_name is supposed to be the streaming sync client's hostname (i.e. node name). Recovery settings on the client (db01.example.com) look like this (managed by the pgsql resource agent): primary_conninfo = 'host=10.1.33.187 port=5432 user=replication application_name=db01 keepalives_idle=60 keepalives_interval=5 keepalives_count=5' restore_command = '' recovery_target_timeline = 'latest' primary_slot_name = 'repl_slot_db01' The pg_stat_replication view on the master (db02.example.com) looks like this: postgres=# select usename, application_name, client_addr, client_hostname, client_port, state, sync_state from pg_stat_replication; usename | application_name | client_addr | client_hostname | client_port | state | sync_state ------------------+--------------------+-------------+------------------+-------------+-----------+------------ replication | 12/main | 10.1.33.70 | db01.example.com | 58024 | streaming | async As you can see, application_name should be "db01" as defined in primary_conninfo but is "12/main" in pg_stat_replication. Is this a bug in PostgreSQL 12 or is application_name in primary_conninfo no longer the proper way to set the application name? For reference, this replication scenario (also managed by Pacemaker) used to work, and still works, on PostgreSQL 9.5 through 11. We only encountered this problem on PostgreSQL 12.2. Please let me know if there is any more relevant information I can provide.
В списке pgsql-bugs по дате отправления: