Hello. At Thu, 11 Jun 2026 15:50:19 +0800, "cca5507" <[email protected]> wrote in > > I think pg_rewind is probably using the insert LSN because it wants to > > choose a conservative position as far ahead as possible. It might be > > possible to use the flush LSN if the copying logic is carefully > > arranged, but I would prefer to keep using the insert LSN if we can. > > The insert LSN is not crash safe, is this really make sense to use it? For > example, the primary has insert LSN 1000, flush LSN 500, the standby > sets minRecoveryPoint to 1000, and then the primary crash and restart. > The primary now only has LSN 500, but the standby cannot reach > consistent until LSN 1000. This doesn’t make sense to me.
My understanding had been that the state produced by pg_rewind only needed to be valid with respect to the source server at the time pg_rewind was run. If the expectation is that the rewound standby must also remain usable after the source server subsequently goes through crash recovery, then I agree that using the insert LSN becomes harder to justify. > I had thought about this before. To update minRecoveryPoint in place, I think > we > should make sure that it won't cause any side effects. That means we need to > check every places we use minRecoveryPoint. That's why the v1 patch introduces > GetEffectiveMinRecoveryPoint() rather than updates it in place. The reason I suggested that approach in my earlier email was simply that, as far as I could tell, that was the only place that needed to interpret a minRecoveryPoint value. That said, since minRecoveryPoint is expected to point to the end of the last required record, I think normalizing the value earlier would also be reasonable. Anyway, if we decide to use the flush LSN instead, then none of this should be necessary. Regards, -- Kyotaro Horiguchi NTT Open Source Software Center
