On Thu, 2025-10-23 at 21:54 +0000, Dmitry Litvintsev wrote: > I have been setting PITR backup off of base backup. Wal files are shipped to > the host running pg_basebackup pulling backup from 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 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 read the code, and that means the following: - PostgreSQL tries to restore a *.history file to get the timeline history - it calls "restore_command" to get the next history file and names it RECOVERYHISTORY locally - "restore_command" exits with a return code 0, but the file is not in "pg_wal" So it is a way for archive restore to fail, but an unusual way. Normally, you would expect "restore_command" to have created the file if it returns 0. So you should improve your "restore_command" if you don't want to see that message. Yours, Laurenz Albe
