>>>>> "Michael" == Michael Paquier <michael@paquier.xyz> writes:
>> So while there _probably_ isn't any data corruption, the standby can
>> get into a state that isn't restartable unless you know to block
>> client connections to it until it has caught up. Rebuilding the
>> standby from the master will work but that may be a significant
>> practical problem if the data is large.
Michael> The problem would show up if you enforce a crash recovery when
Michael> restarting the standby, not after when letting it shut down
Michael> cleanly.
No. The problem shows up on clean shutdowns of the standby too.
For example, I just shut down using pg_ctl stop -mfast the standby side
of the 9.5.14 cluster I've been testing with. Observe:
Database cluster state: shut down in recovery
pg_control last modified: Wed Nov 7 01:47:33 2018
Latest checkpoint location: 0/201FCF70
Prior checkpoint location: 0/C541B40
Latest checkpoint's REDO location: 0/138D2038
...
Minimum recovery ending location: 0/201FCFE0
So the minimum recovery location is recorded as 0x201FCFE0, but there
are data pages on disk with LSNs as recent as 0x25BAFE80. That's a whole
lot of daylight that could contain a btree delete.
--
Andrew (irc:RhodiumToad)
