On Wed, Mar 31, 2010 at 1:47 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
> On Wed, Mar 31, 2010 at 12:21 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> 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.
>
> I'm concerned about that the configuration might prevent the standby
> from accepting connection from a client because it cannot get the WAL
> for making the database consistent. So that configuration seems to be
> reasonable only when starting the standby from the already-consistent
> database or with enough WAL files in pg_xlog. But it seems to me that
> the standby often starts from the inconsistent database without enough
> WAL in pg_xlog.
Agreed. I think if the server starts up in standby mode and it is an
inconsistent state with no source of WAL, then the startup process
should exit with a suitable error message, which AIUI will result in
the whole server shutting down. However if there is no source of WAL
but the server is in a consistent state, then I think we should allow
it to start up as a read-only standby.
Now, an interesting question is - if the server is in this state, and
somebody manually drops more WAL into pg_xlog, what happens? And what
happens in the similar case where primary_conninfo is set but we can't
connect to the master at the moment, and someone drops a pile of WAL
on us?
>> 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. :-(
>
> recovery.conf cannot be reloaded while the server is running. This
> restriction should be removed in the future release, I think.
Yes. If we don't already have a TODO for that, we should definitely
add one. I found myself annoyed by this several times last night. I
kept having to restart the master, too, first to fix archive_mode and
then to fix max_wal_senders. It's far too late to start tinkering
with this stuff now but I am pretty confident there will be a huge
sigh of collective relief out there if we can relax some of these
restrictions for 9.1. Nobody likes having to shut down the server,
even if it's just for a few seconds.
...Robert
