The error I would like to address with this feature is the following:
FATAL: highest timeline xxx of the primary is behind timeline yyy
Where the restored standby for some reason has applied wal files that made is go beyond the currents primary timeline.
Seems to me postgres already had more than enough logic to keep the restored standby's timeline in sync with the primary but is choosing to put out a fatal error instead. This foxes human intervention by having to specify the exact timeline needed to match the primary. I think this could be covered by the proposed option.
On Thu, Sep 11, 2025 at 8:50 PM, Euler Taveira
<euler@eulerto.com> wrote:
On Thu, Sep 11, 2025, at 9:17 PM, Efrain J. Berdecia 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.
>
Do you understand what the timeline is for? [1] You are proposing to implement
exactly what it is protecting you from: overwrite previous archived WAL after a
recovery.
[1]
https://www.postgresql.org/docs/current/continuous-archiving.html#BACKUP-TIMELINES--
Euler Taveira
EDB
https://www.enterprisedb.com/
