could not stat file "pg_wal/RECOVERYHISTORY": No such file or director

Hello,

I have been setting PITR backup off of base backup. Wal files are shipped to the host running pg_basebackup pulling
backupfrom  
master host.

Once base backup finished I wanted to try recovery.

I added

restore_command = 'gunzip /data/xlogs/%f.gz > %p'

(that command is wrapped in a script that checks existence of input and exits w/ 0 if it does not as per instructions)

I did move pg_wal out of the way and re-created it:

mv pg_wal pg_wal.bak
mkdir pg_wal

I did touch recovery signal:

touch recovery.signal

I see in the log:


< 2025-10-23 16:05:30.750 CDT  2876871 > LOG:  database system was interrupted; last known up at 2025-10-23 02:00:41
CDT
< 2025-10-23 16:05:31.582 CDT  2876871 > LOG:  could not stat file "pg_wal/RECOVERYHISTORY": No such file or directory
< 2025-10-23 16:05:31.582 CDT  2876871 > DETAIL:  restore_command returned a zero exit status, but stat() failed.
< 2025-10-23 16:05:31.582 CDT  2876871 > LOG:  starting archive recovery
< 2025-10-23 16:05:31.583 CDT  2876871 > LOG:  starting backup recovery with redo LSN 20975/FE0AC690, checkpoint LSN
20975/FE21CA88,on timeline ID 4 
< 2025-10-23 16:05:31.586 CDT  2876871 > LOG:  could not stat file "pg_wal/RECOVERYHISTORY": No such file or directory
< 2025-10-23 16:05:31.586 CDT  2876871 > DETAIL:  restore_command returned a zero exit status, but stat() failed.
< 2025-10-23 16:05:31.798 CDT  2876871 > LOG:  restored log file "0000000400020975000000FE" from archive
< 2025-10-23 16:05:31.819 CDT  2876871 > LOG:  redo starts at 20975/FE0AC690
< 2025-10-23 16:05:33.927 CDT  2876871 > LOG:  restored log file "0000000400020975000000FF" from archive

it seems to be churning on, but I am a bit worried about :

could not stat file "pg_wal/RECOVERYHISTORY": No such file or directory

I do not recall having to deal with this in the past? Should I have manually created

pg_wal/archive_status

my old scripts seem to indicate the need for this - I am trying to resurrect
PITR after multiple upgrades and not running it for some time (relying in replica instead)

So, is it harmless? Postgresql does not fail, the recovery is still ongoing.

This is postgresql 15.

Additional question.... as the wall file are continuously getting shipped to the backup host,
will this recovery ever end?  (I neglected to set recovery_target_time)

Thank you very much in advance