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

From Bertrand Drouvot
Subject Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution
Date
Msg-id arTtQeXjXFVcycpK@bdtpg
Whole thread
In response to Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution  (Xuneng Zhou <xunengzhou@gmail.com>)
Responses Re: Logical slot creation/synchronization on a standby may deadlock with recovery conflict resolution
List pgsql-hackers
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.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com



pgsql-hackers by date:

Previous
From: shveta malik
Date:
Subject: Re: Fix "unexpected logical decoding status change" error; from concurrent logical decoding activation
Next
From: Nitin Jadhav
Date:
Subject: Expose redo start information in pg_stat_recovery