On Thu, Jan 8, 2026 at 6:29 PM Xuneng Zhou <[email protected]> wrote: > On Thu, Jan 8, 2026 at 10:19 PM Alexander Korotkov <[email protected]> > 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. ------ Regards, Alexander Korotkov Supabase
