MIME-Version: 1.0
References: <CABPTF7Xs-64GQNjmbimZNhj2YSKbBny+evz6=cp3X2fkJS+vMQ@mail.gmail.com>
 <202601011659.ikh4ku4p3ovb@alvherre.pgsql> <CAPpHfduDVNo4VXgnQFZUg9=2yHQJfUUqjokbi3qVxuJiKNfcwg@mail.gmail.com>
 <CABPTF7UkwQZGx5ub731Q+=+rU8yx4ruqMdDt__L_dm9_32LsMw@mail.gmail.com>
 <CAPpHfds-KiZRuCruc0jHxLSxLqzKcHJGwOFFA0b_RgaJvtUOEQ@mail.gmail.com>
 <CABPTF7Vy4A0S0W7=B-fVd9Bo_15XG_FRYfKUF2CB_i=5svwEZQ@mail.gmail.com>
 <CA+hUKG+L0OQR8dQtsNBSaA3FNNyQeFabdeRVzurm0b7Xtp592g@mail.gmail.com>
 <iuzfab2lr54iarbt5ijxtkdbrkv5qnioykluu7pg53hn7gv2te@hz2bkg4aw7bi>
 <CABPTF7WN_3kDPBYPxaKKcp2kO5BLB5bK_YGz70VTzTCivHibZA@mail.gmail.com>
 <CAPpHfdtu0zPDnpw1meVAeWaBXen245QmVP=NpOv2gcy4O9ObBA@mail.gmail.com> <CABPTF7Ub=w7CRxi3sNv8oMGMh4hCqUTohuiTuP9Y1DpxRuFtRQ@mail.gmail.com>
In-Reply-To: <CABPTF7Ub=w7CRxi3sNv8oMGMh4hCqUTohuiTuP9Y1DpxRuFtRQ@mail.gmail.com>
From: Alexander Korotkov <aekorotkov@gmail.com>
Date: Thu, 8 Jan 2026 22:42:03 +0200
Message-ID: <CAPpHfduJKv9-R2HcpyX9RNgteLL0M1MPS1No1WLnTsegsbG4MQ@mail.gmail.com>
Subject: Re: Implement waiting for wal lsn replay: reloaded
To: Xuneng Zhou <xunengzhou@gmail.com>
Cc: Andres Freund <andres@anarazel.de>, Thomas Munro <thomas.munro@gmail.com>, 
	=?UTF-8?Q?=C3=81lvaro_Herrera?= <alvherre@kurilemu.de>, 
	Chao Li <li.evan.chao@gmail.com>, pgsql-hackers <pgsql-hackers@lists.postgresql.org>, 
	Michael Paquier <michael@paquier.xyz>, jian he <jian.universality@gmail.com>, 
	Tomas Vondra <tomas@vondra.me>, Yura Sokolov <y.sokolov@postgrespro.ru>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CAPpHfduJKv9-R2HcpyX9RNgteLL0M1MPS1No1WLnTsegsbG4MQ%40mail.gmail.com>
Precedence: bulk

On Thu, Jan 8, 2026 at 6:29=E2=80=AFPM Xuneng Zhou <xunengzhou@gmail.com> w=
rote:
> On Thu, Jan 8, 2026 at 10:19=E2=80=AFPM Alexander Korotkov <aekorotkov@gm=
ail.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.

------
Regards,
Alexander Korotkov
Supabase