Re: walreceiver fallback_application_name
От | Magnus Hagander |
---|---|
Тема | Re: walreceiver fallback_application_name |
Дата | |
Msg-id | AANLkTi=W9dpCj2K+89rT7j8Ko+Chkix7=ixNLoV9Caxr@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: walreceiver fallback_application_name (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: walreceiver fallback_application_name
|
Список | pgsql-hackers |
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/
В списке pgsql-hackers по дате отправления: