Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution

On Thu, Sep 24, 2026 at 7:00 PM Xuneng Zhou <xunengzhou(at)gmail(dot)com> wrote:
>
> On Thu, Sep 24, 2026 at 5:28 PM Bertrand Drouvot
> <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote:
> >
> > Hi,
> >
> > On Thu, Sep 24, 2026 at 03:49:35PM +0800, Xuneng Zhou wrote:
> > > Hi hackers,
> > >
> > > I don't see a clear solution to this potential issue, because the interface
> > > is a function, which means that the held snapshots cannot be popped cleanly
> > > since they belong to the surrounding executor.
> >
> > Thanks for the report and reproducers!
> >
> > Thinking out loud, I wonder if we could add a transient PGPROC state while a
> > backend depends on recovery replay. After deadlock_timeout, ResolveRecoveryConflictWithVirtualXIDs()
> > could check whether a VXID in its waitlist has that state set and, if so, use the
> > existing recovery conflict cancellation path.
> >
> > Does that make sense to you and others? If so, I can have a look at preparing a
> > patch.
>
> The overall direction looks promising to me, and I haven't come up
> with a simpler fix. As a side benefit, it could also break the
> potential deadlock where 'WAIT' command waits for replay while
> recovery waits for the same backend's VXID. It would be good to hear
> more echo before heading to implementation.

Here's the reproducer for the mentioned VXID issue. I think we need to
test the fix for it as well, since the underlying issue remains the
same. The reproducers could fit in existing test files like 031, but
for clarity, they are in standalone files. Also CCed Alexander for
this.

--
Regards,
Xuneng Zhou
HighGo Software Co., Ltd.