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

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> You could be bit by any shutdown of the old code, no, whether it's
Tom> part of a pg_upgrade or not?

Nothing to do with pg_upgrade, this is likely to bite people just doing
an update from the previous minor release.

Tom> Also, it looks like the bug only affects standbys (or at least
Tom> that's what the commit message seems to imply), which makes it
Tom> less of a data-loss hazard than it might've been.

The commit message doesn't really show the severity of the problem at
all.

The problem is this: the updating of minRecoveryPoint in the control
file is almost completely broken in the last point releases. It's not an
"incorrect calculation" as the commit message says, it's that the
bgwriter and checkpointer _do not update the value at all_ except
immediately after a checkpoint. That means that it is common to have a
situation where the recovery restartpoint is at lsn X, the
minRecoveryPoint is at a slightly later lsn Y, but there are on-disk
data pages with a _much_ later lsn Z.

If such a data page was the subject of a Btree/DELETE record, then any
attempt to do recovery will potentially PANIC with a (false) "WAL
contains references to invalid pages" error -- if, and only if, at least
one client (e.g. a monitoring system) is connected when the record is
replayed, which is possible because of the incorrect minRecoveryPoint.

The users whose case I was diagnosing on IRC were finding that their
monitoring system was sufficient to trigger the problem at least 80% of
the time. Consider that the broken minRecoveryPoint can be quite a long
way in the past relative to on-disk data pages, so the window of
vulnerability isn't necessarily small.

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.

--
Andrew (irc:RhodiumToad)