On Thursday, September 11, 2025, 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
> inconsisten
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
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 wh
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 inconsist
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
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
This option would only be applicable when the standby.signal file is used only
for restoring a cluster for the purposes of establishing a standby replica.
Yahoo Mail: Search, Organize, Conquer
On Thu, Sep 11, 2025 at 8:50 PM, Euler Taveira wrote: On
Thu, Sep 11, 2025, at 9:17 PM, Efrain J
