walreceiver fallback_application_name - Mailing list pgsql-hackers

From Magnus Hagander
Subject walreceiver fallback_application_name
Date
Msg-id AANLkTin4q=9AcT33y=4qjDnOXn9okOda1UteT7rKrS+U@mail.gmail.com
Whole thread Raw
Responses Re: walreceiver fallback_application_name  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Since we now show the application name in pg_stat_replication, I think
it would make sense to have the walreceiver set
fallback_application_name on the connection string, like so:

diff --git a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
b/src/backend/replication/libpqwalreceiver/libpqwalreceiv
index c052df2..962ee04 100644
--- a/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
+++ b/src/backend/replication/libpqwalreceiver/libpqwalreceiver.c
@@ -92,7 +92,7 @@ libpqrcv_connect(char *conninfo, XLogRecPtr startpoint)    * "replication" for .pgpass lookup.    */
snprintf(conninfo_repl, sizeof(conninfo_repl), 
-            "%s dbname=replication replication=true",
+            "%s dbname=replication replication=true
fallback_application_name=postgres",            conninfo);
   streamConn = PQconnectdb(conninfo_repl);


Using fallback_application_name, it can still be overridden in
primary_conninfo if the user wants to use it to separate different
instances.

Any objections to that?

--
 Magnus Hagander
 Me: http://www.hagander.net/
 Work: http://www.redpill-linpro.com/


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: pg_stat_replication security
Next
From: Magnus Hagander
Date:
Subject: Re: Recovery control functions