BUG #19477: pg_rewind does not rewind a diverging timeline
PG Bug reporting form <noreply@postgresql.org>
From: PG Bug reporting form <noreply@postgresql.org>
To: pgsql-bugs@lists.postgresql.org
Cc: mats@kindahl.net
Date: 2026-05-14T09:16:38Z
Lists: pgsql-bugs
The following bug has been logged on the website: Bug reference: 19477 Logged by: Mats Kindahl Email address: mats@kindahl.net PostgreSQL version: 18.3 Operating system: All Description: There is one scenario that I assume is known that TLC found, but does not seem to be fixed. It is a relatively rare case, but since the fix is quite easy, I thought I'd share it with you and get feedback. The scenario can occur if you're unlucky and have more than one crash when promoting standbys to be primaries, and goes like this: You have three servers, S1, S2, and S3. S1 is primary and S2 and S3 are standbys. All are on timeline (TLI) 1. 1. S1 crashes 2. S1 recovers and starts promotion. It writes XLOG_END_OF_RECOVERY (EOR) for TLI 2 to the WAL. 3. S1 It manages to write some records W1 to the WAL. 4. Before the EOR is replicated to any standby, S1 crashes again. It is now on TLI 2 and has some changes that are not elsewhere. 5. S2 is promoted. It writes an EOR for TLI 2 (since it is not aware of any other timeline) to the WAL. 6. S2 writes some records W2 to WAL and now S1 has a record of TLI 2 version 1 (TLI 2.1) and S2 is on TLI 2.2. 7. S1 recovers and wants to join as a standby. You run pg_rewind to get rid of the extra data, but since S2 is also on TLI 2, pg_rewind will happily assume that both are on the same timeline. 8. S2 is now a standby but has that extra record for W2 both in the WAL and in the database. There is a fix posted in pgsql-hackers@lists.postgresql.org [1] that solves it by adding a UUIDv7 to the timeline history file. [1]: https://www.postgresql.org/message-id/flat/CAN305gBeJr8m7ZRW9mH0zakEFR4hDUPDo8fJRKJOHWMORG5_Bg%40mail.gmail.com