On Thu, Jan 28, 2010 at 12:27 AM, Heikki Linnakangas <hei...@postgresql.org> wrote: > Log Message: > ----------- > Make standby server continuously retry restoring the next WAL segment with > restore_command, if the connection to the primary server is lost. This > ensures that the standby can recover automatically, if the connection is > lost for a long time and standby falls behind so much that the required > WAL segments have been archived and deleted in the master. > > This also makes standby_mode useful without streaming replication; the > server will keep retrying restore_command every few seconds until the > trigger file is found. That's the same basic functionality pg_standby > offers, but without the bells and whistles.
http://archives.postgresql.org/pgsql-hackers/2010-01/msg01520.php http://archives.postgresql.org/pgsql-hackers/2010-01/msg02589.php As I pointed out previously, the standby might restore a partially-filled WAL file that is being archived by the primary, and cause a FATAL error. And this happened in my box when I was testing the SR. sby [20088] FATAL: archive file "000000010000000000000087" has wrong size: 14139392 instead of 16777216 sby [20076] LOG: startup process (PID 20088) exited with exit code 1 sby [20076] LOG: terminating any other active server processes act [18164] LOG: received immediate shutdown request If the startup process is in standby mode, I think that it should retry starting replication instead of emitting an error when it finds a partially-filled file in the archive. Then if the replication has been terminated, it has only to restore the archived file again. Thought? Regards, -- Fujii Masao NIPPON TELEGRAPH AND TELEPHONE CORPORATION NTT Open Source Software Center -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
