Hi Adam, Michael, I went through the discussion and wanted to share my thoughts.
I agree with Michael's point that semantically, minRecoveryPoint represents the minimum LSN needed for on-disk page consistency, and from that strict perspective, the current behavior is technically correct. However, I also acknowledge Adam's concern about the practical impact on tooling and automation that relies on pg_controldata to accurately reflect recovery progress. Given that the current behavior creates inconsistency across recovery_target_action settings (pause and promote behave differently than shutdown), external tools such as pg_rewind, backup solutions, and monitoring systems depend on this value for operational decisions, I support moving forward with this patch. Regarding Michael's point about simplifying the minRecoveryPoint update logic—I completely agree that reducing code paths and complexity in this area would be valuable. If there are specific areas that could benefit from simplification or refactoring, I would be interested in helping with that work. I haven't reviewed the patch in detail yet, but I will do so and share any feedback or comments. Best Regards, Nitin Jadhav Azure Database for PostgreSQL Microsoft
