Re: [BUG] Take a long time to reach consistent after pg_rewind

Hello.

At Thu, 11 Jun 2026 15:50:19 +0800, "cca5507" <cca5507(at)qq(dot)com> 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