Re: WAL File Recovery on Standby Server Stops Before End of WAL Files - Mailing list pgsql-general

From Kyotaro Horiguchi
Subject Re: WAL File Recovery on Standby Server Stops Before End of WAL Files
Date
Msg-id 20211028.105831.1248025594517640647.horikyota.ntt@gmail.com
Whole thread Raw
In response to WAL File Recovery on Standby Server Stops Before End of WAL Files  ("Ryan, Les" <Les.Ryan@wsp.com>)
Responses Re: WAL File Recovery on Standby Server Stops Before End of WAL Files
List pgsql-general
At Wed, 27 Oct 2021 16:42:52 +0000, "Ryan, Les" <Les.Ryan@wsp.com> wrote in 
> 2021-10-27 10:26:31.467 MDT [2012] LOG:  redo starts at 419/5229A858
...
> 2021-10-27 10:26:36.188 MDT [2012] LOG:  restored log file "00000001000004190000005A" from archive
> 2021-10-27 10:26:36.750 MDT [2012] LOG:  consistent recovery state reached at 419/5ABFFFF8
> 2021-10-27 10:26:36.752 MDT [6204] LOG:  database system is ready to accept read only connections
> 2021-10-27 10:26:36.823 MDT [6040] LOG:  started streaming WAL from primary at 419/5A000000 on timeline 1
> 
>   *   There are many more WAL files available starting with 00000001000004190000005B but the restore process always
stopsat 00000001000004190000005A.
 
> 
> I have two questions:
> 
>   *   Why does the WAL file recovery process now stop after it reads 00000001000004190000005A?
>   *   What do I need to do to get PostgreSQL to recover the rest of the available WAL files.

The info above alone donesn't clearly suggest anything about the
reason. Could you show the result of "pg_waldump
00000001000004190000005A 2>&1 | tail -5"?  What I'm expecting to see
is an error message from pg_waldump before the end of the file. It
would be the immediate cause of the problem.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-general by date:

Previous
From: "David G. Johnston"
Date:
Subject: Re: jsonb: unwrapping text
Next
From: Dilip Kumar
Date:
Subject: Re: WAL File Recovery on Standby Server Stops Before End of WAL Files