Re: [HACKERS] walreceiver fallback_application_name
--On 16. Januar 2011 21:53:47 +0100 Dimitri Fontaine dimi...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
On Mon, Jan 17, 2011 at 04:05, Fujii Masao masao.fu...@gmail.com wrote: On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Magnus Hagander mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
On Mon, Jan 17, 2011 at 10:57, Magnus Hagander mag...@hagander.net wrote: On Mon, Jan 17, 2011 at 04:05, Fujii Masao masao.fu...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
Fujii Masao masao.fu...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
On Sun, Jan 16, 2011 at 17:29, Tom Lane t...@sss.pgh.pa.us wrote: Magnus Hagander mag...@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/ -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] walreceiver fallback_application_name
On Mon, Jan 17, 2011 at 11:16 AM, Robert Haas robertmh...@gmail.com wrote: On Sun, Jan 16, 2011 at 3:53 PM, Dimitri Fontaine dimi...@2ndquadrant.fr wrote: Magnus Hagander mag...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
