Re: First-draft release notes for back-branch releases

>>>>> "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)