Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution - Mailing list pgsql-hackers

From Xuneng Zhou
Subject Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution
Date
Msg-id CABPTF7UhFbjc0aCB0tdPDAbYNJ9hX5FanuhUNnbcmWif-ZeBgw@mail.gmail.com
Whole thread
In response to Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution  (Bertrand Drouvot <bertranddrouvot.pg@gmail.com>)
Responses Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution
List pgsql-hackers
On Thu, Sep 24, 2026 at 5:28 PM Bertrand Drouvot
<bertranddrouvot.pg@gmail.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.

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



pgsql-hackers by date:

Previous
From: Antonin Houska
Date:
Subject: Re: REPACK enhancements
Next
From: Jakub Wartak
Date:
Subject: Re: Continuous re-validation of session credentials