Re: Parameter name standby_mode

On Wed, Mar 31, 2010 at 4:54 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> Robert Haas wrote:
>> 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?
>
> With the recent changes to the retry logic
> (http://archives.postgresql.org/pgsql-committers/2010-03/msg00356.php),
> they will be replayed. Even if neither primary_conninfo or
> restore_command is given, the server will still keep polling pg_xlog,
> and if you copy a WAL file to standby's pg_xlog directory, it will be
> replayed and recovery will make progress.
>
> I wouldn't recommend setting up a standby server like that, but it's not
> totally unreasonable. So the standby always has a potential source of
> WAL, pg_xlog.

OK.

Is it reasonable to think that we can find a way to make it not print
the duplicate messages over and over again?

LOG: record with zero length at 0/3006B28

Maybe only print that if the location has advanced since the last such message?

Should we make it shut down if it can't immediately read enough WAL to
get to a consistent state, or just figure it's the user's job to fix
it?

...Robert