On Mon, May 10, 2021 at 2:05 PM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
> I thought that the reason using receiveTLI instead of
> recoveryTargetTLI here is that there's a case where receiveTLI is the
> future of recoveryTarrgetTLI but I haven't successfully had such a
> situation. If I set recovoryTargetTLI to a TLI that standby doesn't
> know but primary knows, validateRecoveryParameters immediately
> complains about that before reaching there. Anyway the attached
> assumes receiveTLI may be the future of recoveryTargetTLI.
If you see the note in this commit. It says without the timeline
history file, so does it trying to say that although receiveTLI is the
ancestor of recovoryTargetTLI, it can not detect that because of the
absence of the TL.history file ?
ee994272ca50f70b53074f0febaec97e28f83c4e
Author: Heikki Linnakangas <heikki.linnakangas@iki.fi> 2013-01-03 14:11:58
Committer: Heikki Linnakangas <heikki.linnakangas@iki.fi> 2013-01-03 14:11:58
.....
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.
=====
>
> I believe the 004_timeline_switch.pl detects your issue. And the
> attached change fixes it.
I think this fix looks better to me, but I will think more about it
and give my feedback. Thanks for quickly coming up with the
reproducible test case.
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com