On 08/12/2018 02:56 PM, Phil Endecott wrote:
> Stephen Frost wrote:
>
> Specifically, section 26.2.5 of the docs says:
>
> "If you use streaming replication without file-based continuous archiving,
> the server might recycle old WAL segments before the standby has received
> them. If this occurs, the standby will need to be reinitialized from a new
> base backup. You can avoid this by setting wal_keep_segments to a value
> large enough to ensure that WAL segments are not recycled too early, or by
> configuring a replication slot for the standby. If you set up a WAL archive
> that's accessible from the standby, these solutions are not required, since
> the standby can always use the archive to catch up provided it retains
> enough
> segments."
>
> OR, maybe the WAL reader that process the files that restore_command
> fetches
> could be smart enough to realise that it can skip over the gap at the end?
>
> Anyway. Do others agree that my issue was the result of
> wal_keep_segments=0 ?
Only as a sub-issue of the slave losing contact with the master. The
basic problem is maintaining two separate operations, archiving and
streaming, in sync. If either or some combination of both lose
synchronization then it is anyone's guess on what is appropriate for
wal_keep_segments.
>
>
> Regards, Phil.
>
>
>
>
>
>
--
Adrian Klaver
adrian.klaver@aklaver.com