On Wed, 2010-03-31 at 23:54 +0300, Heikki Linnakangas 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.
I have inadvertently made it impossible to specify standby_mode && (!primary_conninfo && !restore_command)
I did that because Robert had separately to this thread reported a hang,
caused by this specification. I have verified this.
pg_xlog is a *potential* source of WAL, but if the files requested are
not present then the server just sits and waits with *no* messages. That
is unacceptable, IMHO.
What should we do now?
-- Simon Riggs www.2ndQuadrant.com
