Re: General support on postgres replication

From: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
To: Vijaykumar Patil <vijaykumar(dot)patil(at)maersk(dot)com>, "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org>
Subject: Re: General support on postgres replication
Date: 2023-11-23 11:53:48
Message-ID: 9aa59acdaf3a785db3a7359aba923bc0e7badfe2.camel@cybertec.at
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Thu, 2023-11-23 at 09:32 +0000, Vijaykumar Patil wrote:
> LOG: entering standby mode
> LOG: consistent recovery state reached at 1/27000100
> LOG: database system is ready to accept read-only connections
> LOG: started streaming WAL from primary at 1/28000000 on timeline 36
> LOG: recovery stopping before commit of transaction 25628, time 2023-11-22 04:33:31.454379-05
> LOG: redo done at 1/2800BBB0 system usage: CPU: user: 0.00 s, system: 0.00 s, elapsed: 43.73 s
> FATAL: terminating walreceiver process due to administrator command
> LOG: selected new timeline ID: 37
> LOG: archive recovery complete

When you built your standby, you accidentally set (or copied via pg_basebackup)
an option "recovery_target_*", so recovery stopped at that point, and the standby
server was promoted.

Don't set any of these parameters on the standby server.

This is certainly one of the major problems introduced by commit 2dedf4d9a8:
If you ever recovered a database, you may end up having recovery parameters
set in your configuration file. You don't notice them until you build a
standby server, which will then get into trouble.

Yours,
Laurenz Albe

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Daniel Westermann (DWE) 2023-11-23 13:16:57 Corruption or wrong results with 14.10?
Previous Message Vijaykumar Patil 2023-11-23 09:32:32 RE: General support on postgres replication