On Thu, Jan 28, 2010 at 12:27 AM, Heikki Linnakangas
<heikki@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
