Ensure that a standby is able to follow a primary on a newer timeline.
authorFujii Masao <fujii@postgresql.org>
Thu, 14 Jan 2021 03:27:11 +0000 (12:27 +0900)
committerFujii Masao <fujii@postgresql.org>
Thu, 14 Jan 2021 03:27:11 +0000 (12:27 +0900)
commitfef5b47f6bfc9bfec619bb2e6e66b027e7ff21a3
treea57aefe53c4c90d9bfad39bcd50c035042ded21b
parentaef8948f38d9f3aa58bf8c2d4c6f62a7a456a9d1
Ensure that a standby is able to follow a primary on a newer timeline.

Commit 709d003fbd refactored WAL-reading code, but accidentally caused
WalSndSegmentOpen() to fail to follow a timeline switch while reading from
a historic timeline. This issue caused a standby to fail to follow a primary
on a newer timeline when WAL archiving is enabled.

If there is a timeline switch within the segment, WalSndSegmentOpen() should
read from the WAL segment belonging to the new timeline. But previously
since it failed to follow a timeline switch, it tried to read the WAL segment
with old timeline. When WAL archiving is enabled, that WAL segment with
old timeline doesn't exist because it's renamed to .partial. This leads
a primary to have tried to read non-existent WAL segment, and which caused
replication to faill with the error "ERROR:  requested WAL segment ... has
 already been removed".

This commit fixes WalSndSegmentOpen() so that it's able to follow a timeline
switch, to ensure that a standby is able to follow a primary on a newer
timeline even when WAL archiving is enabled.

This commit also adds the regression test to check whether a standby is
able to follow a primary on a newer timeline when WAL archiving is enabled.

Back-patch to v13 where the bug was introduced.

Reported-by: Kyotaro Horiguchi
Author: Kyotaro Horiguchi, tweaked by Fujii Masao
Reviewed-by: Alvaro Herrera, Fujii Masao
Discussion: https://postgr.es/m/20201209.174314.282492377848029776.horikyota.ntt@gmail.com
src/backend/replication/walsender.c
src/test/recovery/t/004_timeline_switch.pl