On Tuesday, June 16, 2026 5:36 PM Amit Kapila <[email protected]> wrote: > > On Tue, Jun 16, 2026 at 2:24 PM Zhijie Hou (Fujitsu) <[email protected]> > wrote: > > > > > > 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) > > > > + if (dropped) > + ereport(LOG, > + errmsg("dropped replication slot \"%s\" of database with OID %u", > + NameStr(slot_name), > + slot_database)); > > Can we avoid the if (dropped) check by placing this LOG message immediately > after dropping the slot under synced slot check?
I think we can do that. I'm attaching the new patches for all supported branches, incorporating both my and Amit's comments. I hope this helps move the fix forward. I also confirmed that the fix works on all supported branches. Best Regards, Hou zj
v2_PG17-0001-Avoid-stale-slot-access-after-dropping-obsol.patch
Description: v2_PG17-0001-Avoid-stale-slot-access-after-dropping-obsol.patch
v2-0001-Avoid-stale-slot-access-after-dropping-obsolete-s.patch
Description: v2-0001-Avoid-stale-slot-access-after-dropping-obsolete-s.patch
v2_PG18-0001-Avoid-stale-slot-access-after-dropping-obsol.patch
Description: v2_PG18-0001-Avoid-stale-slot-access-after-dropping-obsol.patch
