On Thu, Oct 28, 2021 at 7:28 AM Kyotaro Horiguchi <horikyota.ntt@xxxxxxxxx> wrote: > > At Wed, 27 Oct 2021 16:42:52 +0000, "Ryan, Les" <Les.Ryan@xxxxxxx> 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 stops at 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. +1, that will be the best place to start with, additionally, you can enable DEBUG2 message so that from logs we can identify why it could not continue recovery from the archive. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
