MIME-Version: 1.0
References: <19432-3c569e9472f42cee@postgresql.org> <58ceb75034bf694d52f81e898df35e14122fe5c8.camel@cybertec.at>
In-Reply-To: <58ceb75034bf694d52f81e898df35e14122fe5c8.camel@cybertec.at>
From: Felix Hamme <felix.hamme@ionos.com>
Date: Fri, 13 Mar 2026 09:35:39 +0100
Message-ID: <CAFhNxxTNTx=B5ibHQNVC+MLAG=kwHCed7dCgSYPJfJ24uPjxeQ@mail.gmail.com>
Subject: Re: BUG #19432: recovery fails at invalid checkpoint record
To: Laurenz Albe <laurenz.albe@cybertec.at>
Cc: pgsql-bugs@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAFhNxxTNTx%3DB5ibHQNVC%2BMLAG%3DkwHCed7dCgSYPJfJ24uPjxeQ%40mail.gmail.com>
Precedence: bulk

Thank you for checking, now I found what I did wrong: "mv" doesn't
work as a restore_command because the same .history file is restored
multiple times during recovery.
I successfully recovered using a restore_command which does a cp for
history files and mv for wal files. It logged this:

cp /DBDATA/test/fakearchive/00000002.history pg_wal/RECOVERYHISTORY success
cp /DBDATA/test/fakearchive/00000003.history pg_wal/RECOVERYHISTORY not fou=
nd
cp /DBDATA/test/fakearchive/00000002.history pg_wal/RECOVERYHISTORY success
mv /DBDATA/test/fakearchive/000000010000000000000003 pg_wal/RECOVERYXLOG su=
ccess
mv /DBDATA/test/fakearchive/000000010000000000000004 pg_wal/RECOVERYXLOG su=
ccess
mv /DBDATA/test/fakearchive/000000020000000000000005 pg_wal/RECOVERYXLOG su=
ccess
mv /DBDATA/test/fakearchive/000000020000000000000006 pg_wal/RECOVERYXLOG su=
ccess
mv /DBDATA/test/fakearchive/000000020000000000000007 pg_wal/RECOVERYXLOG su=
ccess
cp /DBDATA/test/fakearchive/00000003.history pg_wal/RECOVERYHISTORY not fou=
nd
cp /DBDATA/test/fakearchive/00000002.history pg_wal/RECOVERYHISTORY success

Is it safe in general to use mv for wal files? In other words, do the
currently supported postgres versions run restore_command only once
per wal file?

Best regards
Felix Hamme


On Thu, Mar 12, 2026 at 8:29=E2=80=AFPM Laurenz Albe <laurenz.albe@cybertec=
.at> wrote:
>
> 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 an=
d
> > 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 pro=
ceed
> > in timeline 2.
> > A 6.7MB tar of the basebackup and the wal archive is available at
> > https://get.hidrive.com/i/PwMejRQG . 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.c=
onf
> 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