pg_rewind: warn when checkpoint hasn't happened after promotion
James Coleman <jtc331@gmail.com>
From: James Coleman <jtc331@gmail.com>
To: pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2022-06-04T12:59:12Z
Lists: pgsql-hackers
Attachments
- v1-0001-pg_rewind-warn-if-we-haven-t-checkpointed-after-p.patch (application/octet-stream) patch v1-0001
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+FD9j617eQFjk1KvQ@mail.gmail.com
Commits
-
pg_rewind: Remove notice in docs about running CHECKPOINT after promote.
- 0a0500207a94 16.0 landed
-
pg_rewind: Fix determining TLI when server was just promoted.
- 009eeee74682 16.0 cited