Re: Change checkpoint‑record‑missing PANIC to FATAL

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

Thank you so much.

> 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?
>
> Just looked at that again, and after a second lookup that still seems
> fine. Applied to close the thread.

I agree that this approach looks cleaner overall. It does feel a bit
artistic but the reduced complexity makes it a worthwhile tradeoff. I
am happy with this approach. Thanks for committing.

> 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.

I don't think that's necessary anymore. Those helpers were primarily
introduced to support the second test, and with the revised approach I
don't see a strong reason to make the changes. Unless you think there
is independent value in the cleanup itself.

Best Regards,
Nitin Jadhav
Azure Database for PostgreSQL
Microsoft