Message-ID: <58ceb75034bf694d52f81e898df35e14122fe5c8.camel@cybertec.at>
Subject: Re: BUG #19432: recovery fails at invalid checkpoint record
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: felix.hamme@ionos.com, pgsql-bugs@lists.postgresql.org
Date: Thu, 12 Mar 2026 20:29:54 +0100
In-Reply-To: <19432-3c569e9472f42cee@postgresql.org>
References: <19432-3c569e9472f42cee@postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: <https://www.postgresql.org/message-id/58ceb75034bf694d52f81e898df35e14122fe5c8.camel%40cybertec.at>
Precedence: bulk

On Thu, 2026-03-12 at 16:20 +0000, PG Bug reporting form wrote:
> Hi, I'm trying to restore from a pg_basebackup at timeline 1 to a
> restore_target_time in timeline 2.
> It fails at "invalid checkpoint record", "could not locate required
> checkpoint record at 0/3000080".
> All relevant wal files are in the archive, the restore_command works and
> backup_label, pg_controldata, pg_waldump and 00000002.history look like
> everything should work.
> Recovering only timeline 1 works, but it fails as soon as it should proce=
ed
> in timeline 2.
> A 6.7MB tar of the basebackup and the wal archive is available at
> https://get.hidrive.com/i/PwMejRQG=C2=A0. This link expires on 2026-03-13=
, I can
> provide a new link if needed.
> Why does this recovery fail?

Funny.  I unpacked your data directory and reduced your postgresql.auto.con=
f
to something that fits my system:

log_min_messages =3D 'DEBUG5'
restore_command =3D 'cp /home/laurenz/hamme/fakearchive/%f %p'
recovery_target_time =3D '2026-03-11 14:51:28 UTC'
recovery_target_action =3D 'promote'
hot_standby_feedback =3D 'on'
log_destination =3D 'csvlog'
log_directory =3D '/home/laurenz/hamme/log'
logging_collector =3D 'on'
wal_level =3D 'logical'
port =3D 5433
unix_socket_directories =3D '/home/laurenz/hamme'
max_connections =3D 300

Recovery worked like a charm.  pg_waldump shows the checkpoint record in
000000010000000000000003 at the correct position.

Not sure what you did wrong.

Yours,
Laurenz Albe