Thread: walreceiver fallback_application_name
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/
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
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/
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