I think this is a good improvement and also like the option (on pg_rewind) to potentially send checkpoints to the source.
Personal anecdote. I was using stolon and frequently failing over. For sometime the rewind was failing that it wasn't required. Only learnt that it's the checkpoint on the source which was missing.
---- On Sat, 04 Jun 2022 05:59:12 -0700 James Coleman <jtc331@gmail.com> wrote ----
A few weeks back I sent a bug report [1] directly to the -bugs mailing list, and I haven't seen any activity on it (maybe this is because I emailed directly instead of using the form?), but I got some time to take a look and concluded that a first-level fix is pretty simple.
A quick background refresher: after promoting a standby rewinding the former primary requires that a checkpoint have been completed on the new primary after promotion. This is correctly documented. However pg_rewind incorrectly reports to the user that a rewind isn't necessary because the source and target are on the same timeline.
Specifically, this happens when the control file on the newly promoted server looks like:
Attached is a patch that detects this condition and reports it as an error to the user.
In the spirit of the new-ish "ensure shutdown" functionality I could imagine extending this to automatically issue a checkpoint when this situation is detected. I haven't started to code that up, however, wanting to first get buy-in on that.