Re: New recovery_target_timeline=primary option

From: "Efrain J(dot) Berdecia" <ejberdecia(at)yahoo(dot)com>
To:
Cc: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: New recovery_target_timeline=primary option
Date: 2025-09-12 05:14:43
Message-ID: 759193077.2828446.1757654083823@mail.yahoo.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

Yahoo Mail: Search, Organize, Conquer

On Thu, Sep 11, 2025 at 9:05 PM, David G. Johnston<david(dot)g(dot)johnston(at)gmail(dot)com> wrote: On Thursday, September 11, 2025, Efrain J. Berdecia <ejberdecia(at)yahoo(dot)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. 

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2025-09-12 05:17:01 Re: Import Statistics in postgres_fdw before resorting to sampling.
Previous Message Amit Kapila 2025-09-12 05:05:09 Re: Add support for specifying tables in pg_createsubscriber.