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