Re: Change checkpoint‑record‑missing PANIC to FATAL

On Fri, Jun 26, 2026 at 12:29:38PM +0530, Nitin Jadhav wrote:
> I went ahead and reworked this to avoid duplication by grouping the
> new coverage into the existing tests that already carry most of the
> setup.

Thanks for that. As promised previously, I have put my mind on this
proposal.

> For the missing-redo path, as discussed above, I added the
> backup_label variant to t/050_redo_segment_missing.pl. 050 already has
> the injection-point setup needed to split redo and checkpoint records
> across WAL segments, so reusing it avoids duplicating that
> orchestration elsewhere.

The refactoring for run_split_checkpoint() and checkpoint_wal_info()
could be a patch of its own, mainly for clarity to as you have wanted
to introduce them for the purpose of the second test.

Hmm, actually.. I am wondering if this could be made simpler by
writing a fully-synthetic backup_label file instead, meaning that we
would not need the dance with the injection points because we could
reuse the redo and checkpoint LSNs of the previous step, then we just
add the checkpoint segment to the starting node's pg_wal/. I admit
that it feels artistic, but it is much less complicated than your
version, more efficient, and would still check the error path we care
about.

Nitin, what do you think about the attached?

> For the missing-checkpoint path, I added the backup_label variant to
> t/042_low_level_backup.pl. 042 already owns the low-level-backup +
> backup_label setup, so it seemed like the natural place. 052 remains
> focused on the no-backup_label checkpoint-missing path.

This one is much simpler compared to the other one, relying on the
removal of pg_wal/ in the initial backup taken from the primary. I
have made the FATAL's regexp a bit more portable, moved the new SQL
query to get the redo segment to be just after the checkpoint
execution, and applied this part.
--
Michael