Prev: pgsql: Make standby server continuously retry restoringthe next WAL
Next: pg_restore --single-transaction and --clean
From: Tom Lane on 12 Feb 2010 09:46 Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> writes: > Joachim Wieland wrote: >> If no primary_conninfo variable is set explicitly in the configuration >> file, check the environment variables. If the environment variable is >> not set, don't try to establish a connection. > The environment variables in question are the libpq environment > variables like PGHOST, PGPORT. The server shouldn't need to know about > them. Even more to the point is that some of them, like PGPORT, are highly likely to be set in a server's environment to point to the server itself. It would be extremely dangerous to automatically try to start replication just because we find those set. In fact, I would argue that we should fix things so that any such variables inherited from the server environment are intentionally *NOT* used for making SR connections. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 15 Feb 2010 01:45 On Fri, Feb 12, 2010 at 11:46 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Even more to the point is that some of them, like PGPORT, are highly > likely to be set in a server's environment to point to the server > itself. It would be extremely dangerous to automatically try to start > replication just because we find those set. In fact, I would argue that > we should fix things so that any such variables inherited from the > server environment are intentionally *NOT* used for making SR > connections. There are many environment variables which libpq automatically uses. Which variables should not be used for SR connection? All? If both primary_conninfo and environment variables are not given, the default value (e.g., port = 5432) is automatically used for SR connection. Is this OK? or NG as well as the environment variables? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 24 Feb 2010 00:18 On Fri, Feb 12, 2010 at 4:59 PM, Heikki Linnakangas <heikki.linnakangas(a)enterprisedb.com> wrote: > Joachim Wieland wrote: >> On Fri, Feb 12, 2010 at 7:28 AM, Fujii Masao <masao.fujii(a)gmail.com> wrote: >>> Yeah, even if primary_conninfo is not given, the standby tries to invoke >>> walreceiver by using the another connection settings (environment variables >>> or defaults). This is intentional behavior, and would make the setup of SR >>> easier. So I'd like to leave it be. >> >> On the other hand, if it has to use defaults for the target host/port, >> chances are high that either it connects to the wrong host/port or >> that SR is just not wanted :-) > > Agreed. I've changed it now so that if primary_conninfo is not set, it > doesn't try to establish a streaming connection. If you want to get the > connection information from environment variables, you can use > primary_conninfo=''. If standby_mode is enabled, and neither primary_conninfo nor restore_command are set, the standby would get stuck. How about forbidding (i.e., causing a FATAL message) this wrong setting? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Fujii Masao on 3 Mar 2010 07:41 On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > If standby_mode is enabled, and neither primary_conninfo nor restore_command > are set, the standby would get stuck. How about forbidding (i.e., causing a > FATAL message) this wrong setting? Here is the patch which forbids that wrong setting of recovery.conf. Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center
From: Fujii Masao on 30 Mar 2010 00:26
On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: > On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao <masao.fujii(a)gmail.com> wrote: >> If standby_mode is enabled, and neither primary_conninfo nor restore_command >> are set, the standby would get stuck. How about forbidding (i.e., causing a >> FATAL message) this wrong setting? > > Here is the patch which forbids that wrong setting of recovery.conf. I think that this patch should be applied. Otherwise, if you wrongly set neither primary_conninfo nor restore_command in recovery.conf, the standby server would do nothing and get stuck because it doesn't know where to retrieve the WAL files from. Banning the incorrect setting makes sense to me. Does anyone commit the patch? Does anyone have a say? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |