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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
