On Tue, Mar 2, 2021 at 3:14 PM Dilip Kumar <dilipbal...@gmail.com> wrote:
> =====
> ee994272ca50f70b53074f0febaec97e28f83c4e
> Author: Heikki Linnakangas <heikki.linnakan...@iki.fi> 2013-01-03 14:11:58
> Committer: Heikki Linnakangas <heikki.linnakan...@iki.fi> 2013-01-03 14:11:58
>
> Delay reading timeline history file until it's fetched from master.
>
> Streaming replication can fetch any missing timeline history files from
> the
> master, but recovery would read the timeline history file for the target
> timeline before reading the checkpoint record, and before walreceiver has
> had a chance to fetch it from the master. Delay reading it, and the sanity
> checks involving timeline history, until after reading the checkpoint
> record.
>
> There is at least one scenario where this makes a difference: if you take
> a base backup from a standby server right after a timeline switch, the
> WAL segment containing the initial checkpoint record will begin with an
> older timeline ID. Without the timeline history file, recovering that file
> will fail as the older timeline ID is not recognized to be an ancestor of
> the target timeline. If you try to recover from such a backup, using only
> streaming replication to fetch the WAL, this patch is required for that to
> work.
> =====
The above commit avoid initializing the expectedTLEs from the
recoveryTargetTLI as shown in below hunk from this commit.
@@ -5279,49 +5299,6 @@ StartupXLOG(void)
*/
readRecoveryCommandFile();
- /* Now we can determine the list of expected TLIs */
- expectedTLEs = readTimeLineHistory(recoveryTargetTLI);
-
I think the fix for the problem will be that, after reading/validating
the checkpoint record, we can free the current value of expectedTLEs
and reinitialize it based on the recoveryTargetTLI as shown in the
attached patch?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com
From 680272add19e8856503da78437ec5080c99b6fb7 Mon Sep 17 00:00:00 2001
From: Dilip Kumar <dilipkumar@localhost.localdomain>
Date: Tue, 4 May 2021 17:04:45 +0530
Subject: [PATCH] After reading checkpoint record fix expectedTLEs to point to
recoveryTargetTLI
As part of the commit ee994272ca50f70b53074f0febaec97e28f83c4e, we have detalayed
reading the timeline history file but recoveryTargetTLI is pointing to the target
timeline. And once it read the checkpoint record it initialize the expectedTLEs
based on the checkpoint record timeline history which change the meaning of the
expectedTLEs which says that it should always point to the recoveryTargetTLI.
So this patch fixes this by re initializing the expectedTLEs based on the
recoveryTargetTLI, after reading the checkpoint record.
---
src/backend/access/transam/xlog.c | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/src/backend/access/transam/xlog.c b/src/backend/access/transam/xlog.c
index adfc6f6..952d2b7 100644
--- a/src/backend/access/transam/xlog.c
+++ b/src/backend/access/transam/xlog.c
@@ -6880,6 +6880,13 @@ StartupXLOG(void)
LastRec = RecPtr = checkPointLoc;
+ /*
+ * Release the current expectedTLEs which is used for reading the
+ * checkpoint record. And, reinitialize based on the recoveryTargetTLI.
+ */
+ list_free_deep(expectedTLEs);
+ expectedTLEs = readTimeLineHistory(recoveryTargetTLI);
+
ereport(DEBUG1,
(errmsg_internal("redo record is at %X/%X; shutdown %s",
LSN_FORMAT_ARGS(checkPoint.redo),
--
1.8.3.1
