Date: Mon, 30 Jun 2025 23:03:31 +0200
From: Christoph Moench-Tegeder <cmt@burggraben.net>
To: Franklin Anderson de Oliveira Souza <franklinbr@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Subject: Re: Simulate a PITR in postgresql 16
Message-ID: <aGL7o4j8hx7ZtEh9@elch.exwg.net>
References: <CAB_Px=yO5y-6NcZjyDxLUGb4m6VX=-UXhSiuB7eLXp10eRfdQw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <CAB_Px=yO5y-6NcZjyDxLUGb4m6VX=-UXhSiuB7eLXp10eRfdQw@mail.gmail.com>
User-Agent: Mutt/2.2.14 (2025-02-20)
Archived-At: <https://www.postgresql.org/message-id/aGL7o4j8hx7ZtEh9%40elch.exwg.net>
Precedence: bulk

## Franklin Anderson de Oliveira Souza (franklinbr@gmail.com):

> LOG: database system was shut down at 2025-06-30 12:15:28 -04
> cp: cannot stat '/dados/temp/wals/00000002.history': No such file or directory
> -----------------
> 
> 
> The restore_command requires the .history file but it does not exist
> in any of the clusters in this simple test, which is wrong in this
> example ? Tanks

Everything is fine - as long as the next log line starts with "starting
backup recovery". Your cluster starts on timeline 1, and the (default)
recovery_target_timeline is "latest", so the recovery process needs
to check if other timelines exist and what the latest timeline is.
It's just that the stderr from cp ends up in your log.
See
https://www.postgresql.org/docs/17/continuous-archiving.html#BACKUP-TIMELINES
for details on timelines.

Regards,
Christoph

-- 
Spare Space