]> git.ipfire.org Git - thirdparty/postgresql.git/commit
Fix scenario where streaming standby gets stuck at a continuation record.
authorHeikki Linnakangas <heikki.linnakangas@iki.fi>
Fri, 4 May 2018 22:34:53 +0000 (01:34 +0300)
committerHeikki Linnakangas <heikki.linnakangas@iki.fi>
Fri, 4 May 2018 22:35:15 +0000 (01:35 +0300)
commit4ea8f7d4553e1b90974766ab6e9a32726e80badc
tree8bf4ce826045d81edf62c389a76e6664f957a98f
parentc1f3638d21a000ea93d4ebcf7e1f34fa92f4cc35
Fix scenario where streaming standby gets stuck at a continuation record.

If a continuation record is split so that its first half has already been
removed from the master, and is only present in pg_wal, and there is a
recycled WAL segment in the standby server that looks like it would
contain the second half, recovery would get stuck. The code in
XLogPageRead() incorrectly started streaming at the beginning of the
WAL record, even if we had already read the first page.

Backpatch to 9.4. In principle, older versions have the same problem, but
without replication slots, there was no straightforward mechanism to
prevent the master from recycling old WAL that was still needed by standby.
Without such a mechanism, I think it's reasonable to assume that there's
enough slack in how many old segments are kept around to not run into this,
or you have a WAL archive.

Reported by Jonathon Nelson. Analysis and patch by Kyotaro HORIGUCHI, with
some extra comments by me.

Discussion: https://www.postgresql.org/message-id/CACJqAM3xVz0JY1XFDKPP%2BJoJAjoGx%3DGNuOAshEDWCext7BFvCQ%40mail.gmail.com
src/backend/access/transam/xlog.c
src/backend/access/transam/xlogreader.c
src/include/access/xlogreader.h