On Tue, Mar 30, 2010 at 12:26 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Mar 3, 2010 at 9:41 PM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Wed, Feb 24, 2010 at 2:18 PM, Fujii Masao <masao.fujii@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?
I just tested this and it seems to just sit there doing this over and
over again:
LOG: record with zero length at 0/3006B28
I'm not sure that we should forbid this configuration, but the current
behavior doesn't seem right either. ISTM that, in the absence of a
way to get any more WAL, it would be reasonable for the standby server
to just start up and sit there in recovery mode but without actually
advancing recovery, but the repeated log messages are pretty annoying.If we're connected in streaming mode and there is
noactivity on the
primary, we don't emit logs of this type, so it doesn't seem like we
should do that if there is no primary either.
A related question is... do we ever reload recovery.conf? I tried
adding the setting to recovery.conf and doing pg_ctl reload, and it
says that it's "reloading configuration files", but doesn't pick up
the new setting. :-(
...Robert