walreceiver fallback_application_name

From: Magnus Hagander <magnus(at)hagander(dot)net>
To: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: walreceiver fallback_application_name
Date: 2011-01-16 14:41:14
Message-ID: AANLkTin4q=9AcT33y=4qjDnOXn9okOda1UteT7rKrS+U@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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/

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Magnus Hagander 2011-01-16 14:52:29 Re: Recovery control functions
Previous Message Magnus Hagander 2011-01-16 14:35:34 pg_stat_replication security