On Tuesday, June 16, 2026 1:30 PM Xuneng Zhou <[email protected]> wrote: > On Fri, Jun 12, 2026 at 6:54 PM Amit Kapila <[email protected]> > wrote: > > > > On Fri, Jun 12, 2026 at 8:22 AM Xuneng Zhou <[email protected]> > wrote: > > > > > > On Thu, Jun 11, 2026 at 9:19 PM Fujii Masao <[email protected]> > > > In an off-list chat with Zhijie, we kinda thought that holding the > > > lock of a wrong db for a brief time doesn't seem to harm a lot. The > > > concurrent dropping-db operation leads to this issue seems rare in > > > practice. He stated that the deletion of the slot seems unavoidable > > > because we have to acquire the database lock after releasing the > > > replication slot lock to avoid the deadlock with the startup/drop db > > > operation. Therefore, he prefered keeping the design simple and > > > avoiding the fatal issue over doing a broader refactoring work. > > > > > > > +1. I also think this change is not worth it. > > I am also OK with the scope of change made by patch 1.
I have one minor comment for the 0001 patch.
+ NameData slot_name = {0};
...
SpinLockAcquire(&local_slot->mutex);
synced_slot = local_slot->in_use &&
local_slot->data.synced;
+ if (synced_slot)
+ slot_name = local_slot->data.name;
SpinLockRelease(&local_slot->mutex);
We can defer assigning slot_name until after we pass the existing (synced_slot)
check. Since it's a synced slot, no other process can change it at that point,
and we can also skip initializing slot_name. (Please refer to the
attached patch for suggested changes)
Best Regards,
Hou zj
0001-comments_patch
Description: 0001-comments_patch
