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. References https://github.com/sorintlab/stolon/issues/601 And the fix https://github.com/sorintlab/stolon/pull/644 https://github.com/sorintlab/stolon/issues/601 ---- On Sat, 04 Jun 2022 05:59:12 -0700 James Coleman <mailto:jtc...@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: Latest checkpoint's TimeLineID: 4 Latest checkpoint's PrevTimeLineID: 4 ... Min recovery ending loc's timeline: 5 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. Thanks, James Coleman 1: https://www.postgresql.org/message-id/CAAaqYe8b2DBbooTprY4v=bized9qbqvlq+fd9j617eqfjk1...@mail.gmail.com
