>>>>> "Michael" == Michael Paquier <mich...@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)
