On Mon, Nov 24, 2025 at 1:46 AM Amit Kapila <[email protected]> wrote: > > On Fri, Nov 21, 2025 at 9:17 AM Zhijie Hou (Fujitsu) > <[email protected]> wrote: > > > > On Thursday, November 13, 2025 12:56 PM Zhijie Hou (Fujitsu) > > <[email protected]> wrote: > > > > > > > I have been thinking if there a way to avoid holding > > ReplicationSlotControlLock > > exclusively in ReplicationSlotsComputeRequiredXmin() because that could > > cause > > lock contention when many slots exist and advancements occur frequently. > > > > Given that the bug arises from a race condition between slot creation and > > concurrent slot xmin computation, I think another way is that, we acquire > > the > > ReplicationSlotControlLock exclusively only during slot creation to do the > > initial update of the slot xmin. In ReplicationSlotsComputeRequiredXmin(), > > we > > still hold the ReplicationSlotControlLock in shared mode until the global > > slot > > xmin is updated in ProcArraySetReplicationSlotXmin(). This approach prevents > > concurrent computations and updates of new xmin horizons by other backends > > during the initial slot xmin update process, while it still permits > > concurrent > > calls to ReplicationSlotsComputeRequiredXmin(). > > > > Yeah, this seems to work.
+1 > > > Here is an update patch for this approach on HEAD. > > > > Thanks for the patch. > > Sawada-San, are you planning to look into this? Otherwise, I can take > care of it. Yes, I'll review the patch and share some comments soon. Regards, -- Masahiko Sawada Amazon Web Services: https://aws.amazon.com
