Re: BUG #16288: application_name from client's primary_conninfo notset in pg_stat_replication on master

On 09.03.20 15:31, Sergei Kornilov wrote:
> Hello
> 
> Works for me.

Thank you very much for the quick reply and pointing me to the solution!

> Please share results of such queries:
> 
> select * from pg_stat_wal_receiver;
> select * from pg_file_settings where name = 'primary_conninfo';
> 
> Cluster name will be used as fallback application name when no application_name was provided. I think you have
severalprimary_conninfo, one of which is in postgresql.auto.conf that was created by pg_basebackup -R
 

You are absolutely right, there was a postgresql.auto.conf created by
pg_basebackup -R that did not contain the application_name field in the
primary_conninfo setting. Once I deleted that file and reloaded the
PostgreSQL streaming client everything started working as expected.

In the past the Pacemaker resource agent would overwrite any
recovery.conf file that might have been left by pg_basebackup -R so this
discrepancy in primary_conninfo fields would never be a problem.

But now, in accordance with PostgreSQL 12, the Pacemaker resource agent
manages the file /var/lib/pgsql/tmp/recovery.conf which contains the
primary_conninfo setting. That file is included from postgresql.conf:

  include '/var/lib/pgsql/tmp/recovery.conf' # added by pgsql RA

So the file postgresql.auto.conf is no longer deleted or overwritten,
but remains in place, containing a "wrong" primary_conninfo setting.
This trips up the Pacemaker resource agent.

Thank you again for the most valuable pointer! I did not really believe
this could be a proper bug in PostgreSQL itself but I was thoroughly out
of ideas because I did not know or realize that postgresql.auto.conf
even existed.

Much appreciated!

Best regards, Andreas