Re: Implement waiting for wal lsn replay: reloaded

On Fri, Jan 9, 2026 at 9:44 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> 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.

V2 corrected the commit message to state " if the WAIT FOR LSN session
is interrupted by a recovery conflict (e.g., DROP TABLESPACE
triggering conflicts on all backends),". In this case, the statement
is canceled when possible; in some states (idle in transaction or
subtransaction) the session may be terminated.

--
Best,
Xuneng