A typical scenario would be if we have a high availability setup with two replicated clusters, primary and a standby. Throw patroni in the mix to manage automatic failover.
If we use a backup solution like PGbackrest to take full backups and archive the Wal files. Let's say we have a scenario where patroni starts flapping between the clusters and promotes both clusters several times but finally settles and chooses to continue running the primary cluster with an older timeline than the newest timeline in the pgbackrest repo, then when we try to reinit or restore the standby, by default, it will attempt to restore to latest timeline.
Leaving the admins to have to figure out what is the correct timeline to restore to, which at the end of the day needs to match the primary's timeline anyways, regardless of the latest timeline files in the pgbackrest repo.
Is either that or the admins need to go in the archive repo and manually delete the related wall files from the timeline that doesn't match the primary to prevent conflicts.
Is a common scenario.
On Thu, Sep 11, 2025 at 9:05 PM, David G. Johnston
<david.g.johnston@gmail.com> wrote:
On Thursday, September 11, 2025, Efrain J. Berdecia <
ejberdecia@yahoo.com> wrote:
One-line Summary: This new recovery_target_timeline option would ensure that when rebuilding a replica cluster, the recovery stays in the primary cluster's timeline making it fool proof and avoiding recovery timeline inconsistencies.
Business Use-case: Reduce human interaction when rebuilding replicas where unwanted timelines might have been archived in the repo and speed up recovery.
User impact with the change: New parameter option available
Implementation details: I would need a subject matter expert to please make this feature a reality
Estimated Development Time: unknown
Category: Include the text: Restore, replication
Feature requests with this little info are probably better discussed on the -general list to garner support for the idea.
David J.
