> 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
