Re: Unexpected WAL-archive restore behaviour

> On 02/18/2017 02:06, Tomas Vondra wrote:
>
> What do you mean by "became unavailable"? The restore_command may be called for segments that do not exist - that's expected, and I suspect the "gzip: stdin: unexpected end of file" error messages are caused by that.
>

Sorry for my unclear description. I've attached a full slave server log file.
"became unavailable" - i mean that another shell script on master removed necessary WAL segments from archive (segments, which hadn't applyed on slave server).

Here a detailed log of actions:
10:18 replication is working normally, physical replication slot was active and shipped WAL records.
10:19 I stoped slave to make changes in recovery.conf. Master server continued to archive WAL segments, replication slot had become inactive.
10:54 I started the slave server, it reached consistent state and resumed to restore WAL segments from archive.
11:25 Replication slot on the master server was still inactive, it was waiting for connection. Slave was still reading WAL archive segments and was applying them according recovery_min_apply_delay = 30min.
11:27 On master server was started bash script to remove old unnecessary WAL archive segments. Unfortunately in this case shell script has removed 3 necessary WAL segments, which was not applied on slave server yet. Usually, when WAL archive segments unavailable, slave-server starts streaming WAL from primary, but in this case slave continued to restore WAL from archive.

According documentation it's normal, when standby server looks for WAL segments that does not exists. In my case, WAL segments was created by master server normally, but wasn't shipped to slave correctly. I am worrying about possible slave consistency damaging.

Thank you for suggestions.
Regards.