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
