walreceiver fallback_application_name

Magnus Hagander <magnus@hagander.net> writes:

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:

Seems reasonable, but "postgres" is a mighty poor choice of name
for that, no?  I don't have any really great substitute suggestion
--- best I can do offhand is "walreceiver" --- but "postgres" seems
uselessly generic, not to mention potentially confusing compared
to the default superuser name for instance.

regards, tom lane

On Sun, Jan 16, 2011 at 17:29, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Magnus Hagander <magnus@hagander.net> writes:

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:

Seems reasonable, but "postgres" is a mighty poor choice of name
for that, no?  I don't have any really great substitute suggestion
--- best I can do offhand is "walreceiver" --- but "postgres" seems
uselessly generic, not to mention potentially confusing compared
to the default superuser name for instance.

I agree it's not a great name.

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

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

Magnus Hagander <magnus@hagander.net> writes:

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

I think walreceiver is very good here, and the user is already
confronted to such phrasing.

http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS

Also, we're about to extend the technique usage in some other places
such as integrated base backup facility and default archiving solution,
so let's talk about what it's doing, not what for.

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

I think walreceiver is very good here, and the user is already
confronted to such phrasing.

 http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS

I agree that walreceiver is a reasonable default to supply in this case.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

I think walreceiver is very good here, and the user is already
confronted to such phrasing.

 http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS

I agree that walreceiver is a reasonable default to supply in this case.

+1 though I could not find the mention to "walreceiver" in the doc.

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);

Also the size of conninfo_repl needs to be enlarged.

Regards,

--
Fujii Masao
NIPPON TELEGRAPH AND TELEPHONE CORPORATION
NTT Open Source Software Center

--On 16. Januar 2011 21:53:47 +0100 Dimitri Fontaine
<dimitri@2ndQuadrant.fr> wrote:

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

I think walreceiver is very good here, and the user is already
confronted to such phrasing.

http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GU
C-MAX-WAL-SENDERS

Hmm, given this link we have mentioned "standby" multiple times. Wouldn't
it be better to follow that phrasing?

--
Thanks

Bernd

Fujii Masao <masao.fujii@gmail.com> writes:

 http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS

+1 though I could not find the mention to "walreceiver" in the doc.

True, we already use "wal sender", I should have said "similar phrasing".

Regards,
--
Dimitri Fontaine
http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support

On Mon, Jan 17, 2011 at 04:05, Fujii Masao <masao.fujii@gmail.com> wrote:

On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine
<dimitri@2ndquadrant.fr> wrote:

Magnus Hagander <magnus@hagander.net> writes:

Is "walreceiver" something that "the average DBA" is going to realize
what it is? Perhaps go for something like "replication slave"?

I think walreceiver is very good here, and the user is already
confronted to such phrasing.

 http://www.postgresql.org/docs/9.0/interactive/runtime-config-wal.html#GUC-MAX-WAL-SENDERS

I agree that walreceiver is a reasonable default to supply in this case.

+1 though I could not find the mention to "walreceiver" in the doc.

It's on this page:
http://www.postgresql.org/docs/9.0/interactive/warm-standby.html

The word exists a single time in our entire documentation. But I sgree
with Dimitri's comment - we should document *what* is on the other
side (walreceiver) not what it's doing (standby). Because what it's
doing is already visible through the state column.

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);

Also the size of conninfo_repl needs to be enlarged.

Oh, nice catch. Worked perfectly in my testing, but I see why it
should be increased :-)

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

On Mon, Jan 17, 2011 at 10:57, Magnus Hagander <magnus@hagander.net> wrote:

On Mon, Jan 17, 2011 at 04:05, Fujii Masao <masao.fujii@gmail.com> wrote:

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);

Also the size of conninfo_repl needs to be enlarged.

Oh, nice catch. Worked perfectly in my testing, but I see why it
should be increased :-)

Applied with change name and the extension of the buffer.

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