Hi there,
I tested pg_rewind behavior and found a suspicious one.
Consider a scenario like this,
Server A: primary
Server B :replica of A
Server C :replica of B
and somehow A down ,so B gets promoted.
Server A: down
Server B :new primary
Server C :replica of B
In this case, pg_rewind can be used to reconstruct the cascade; the source is C and the target is A.
However, we get error as belows by running pg_rewind.
```
pg_rewind: fetched file "global/pg_control", length 8192
pg_rewind: source and target cluster are on the same timeline
pg_rewind: no rewind required
```
Though A's timeline is 1 and C's is 2 ideally, it says they're on the same timeline.
This is because `pg_rewind` currently uses minRecoveryPointTLI and latest checkpoint's TimelineID to compare the TLI between source and target[1].
Both C's minRecoveryPointTLI and Latest checkpoint's TimelineID are not modified until checkpointing. (even though B's are modified).
And then, if you run pg_rewind immediately, pg_rewind won't work because C and A appear to be on the same timeline. So we have to CHECKPOINT on C before running pg_rewind;
BTW, immediate pg_rewind with cascade standby seems to be already concerned in another discussion[2], but unfortunately missed.
Anyway, I don't think this behavior is kind.
To fix this, should we use another variable to compare TLI?
Or, modify the cascade standby's minRecoveryPointTLI somehow?
Masaki Kuwamura
[1]
https://www.postgresql.org/message-id/flat/9f568c97-87fe-a716-bd39-65299b8a60f4%40iki.fi[2]
https://www.postgresql.org/message-id/flat/aeb5f31a-8de2-40a8-64af-ab659a309d6b%40iki.fi