From: | "Efrain J(dot) Berdecia" <ejberdecia(at)yahoo(dot)com> |
---|---|
To: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: New recovery_target_timeline=primary option |
Date: | 2025-09-12 12:26:18 |
Message-ID: | 1519237058.2896041.1757679978075@mail.yahoo.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Even the documentation states/warns:
"Set restore_command to a simple command to copy files from the WAL archive. If you plan to have multiple standby servers for high availability purposes, make sure that recovery_target_timeline is set to latest (the default), to make the standby server follow the timeline change that occurs at failover to another standby."
By default, recovery_target_timeline is set to latest. What I'm recommending is an option to set it to just follow or stay within the primarie's timeline without having to receive the fatal message stated before that ends up stopping the recovery of the standby.
Supposed we have timelines 1-3 archived in our backup repo. Currently our streaming replication setup is running in timeline 3. But now, we need to restore the primary to timeline 2. We can specify recovery_target_timeline=2 to initially restore the primary. But when I go to reinit or rebuild the standby, why not just add a new option, recovery_target_timeline=primary, that forces the standby to just stay on the primaries timeline without having to figure out the correct timeline for the standby.
Without this new parameter or without specifying the timeline when restoring the standby, the restore will take the standby to timeline 3 and get the fatal error message. This happens a lot on setups using tools like patroni.
Just trying to make the administrator's and HA tools lives a little easier when setting up a standby.
Yahoo Mail: Search, Organize, Conquer
On Thu, Sep 11, 2025 at 9:19 PM, Euler Taveira<euler(at)eulerto(dot)com> wrote: On Thu, Sep 11, 2025, at 10:07 PM, Efrain J. Berdecia wrote:
> The error I would like to address with this feature is the following:
>
> FATAL: highest timeline xxx of the primary is behind timeline yyy
>
It seems your procedure to set up a standby is incorrect. See [1]. You are not
using the base backup from the primary server.
You didn't describe the whole procedure so it is hard to point out where the
problem is.
[1] https://www.postgresql.org/docs/current/warm-standby.html#STANDBY-SERVER-SETUP
--
Euler Taveira
EDB https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Maksim.Melnikov | 2025-09-12 12:39:09 | Preferred use of macro GetPGProcByNumber |
Previous Message | Fujii Masao | 2025-09-12 12:12:09 | Invalid primary_slot_name triggers warnings in all processes on reload |