Re: Implement waiting for wal lsn replay: reloaded

Hi,

On Fri, Jan 9, 2026 at 4:42 AM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
>
> On Thu, Jan 8, 2026 at 6:29 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
> > On Thu, Jan 8, 2026 at 10:19 PM Alexander Korotkov <aekorotkov(at)gmail(dot)com> wrote:
> > > I see, you were right. This is not related to the MyProc->xmin.
> > > ResolveRecoveryConflictWithTablespace() calls
> > > GetConflictingVirtualXIDs(InvalidTransactionId, InvalidOid). That
> > > would kill WAIT FOR LSN query independently on its xmin.
> >
> > I think the concern is valid --- conflicts like
> > PROCSIG_RECOVERY_CONFLICT_SNAPSHOT could occur and terminate the
> > backend if the timing is unlucky. It's more difficult to reproduce
> > though. A check for the log containing "conflict with recovery" would
> > likely catch these conflicts as well.
>
> Yes, I found multiple reasons why xmin gets temporarily set during
> processing of WAIT FOR LSN query. I'll soon post a draft patch to fix
> that.
>
> > > I guess your
> > > patch is the only way to go. It's clumsy to wrap WAIT FOR LSN call
> > > with retry loop, but it would still consume less resources than
> > > polling.
> > >
> >
> > Assuming recovery conflicts are relatively rare in tap tests, except
> > for the explicitly designed tests like 031_recovery_conflict and the
> > narrow timing window that the standby has not caught up while the wait
> > for gets invoked, a simple fallback seems appropriate to me.
>
> Yes, I see. Seems acceptable given this seems the only feasible way to go.
>

Here is the updated patch with recovery conflicts handled.

--
Best,
Xuneng