Expand comment on the slot recheck in drop_local_obsolete_slots().
Amit Kapila <akapila@postgresql.org>
Expand comment on the slot recheck in drop_local_obsolete_slots(). The existing comment explained that a user-created slot could reuse the same shared memory as 'local_slot' during the window between selecting a slot to drop and locking its database, and that we therefore recheck before dropping. It did not, however, spell out the fuller consequence: because local_slot points to a reusable slot-array entry, its fields may already describe a replacement slot, so the earlier drop decision and the slot_database used for locking could relate to an unrelated slot/database. Expand the comment to describe this, and note that the recheck prevents us from dropping a user-created replacement slot while the residual risk (such as briefly locking an unrelated database) is confined to the cycle and is acceptable given the race is rare and non-fatal. No functional change. Author: Fujii Masao <masao.fujii@gmail.com> Author: Xuneng Zhou <xunengzhou@gmail.com> Author: Amit Kapila <amit.kapila16@gmail.com> Discussion: https://postgr.es/m/CAHGQGwGGyEDL3dh7uJ6qPsGvnq4QK_R8+U=12CaprnzwrwaLGA@mail.gmail.com Discussion: https://postgr.es/m/CAHGQGwHqQ1PPVFfYKVxLfRyC-byRdwSN0NeaHj9SLYV97oO5cw@mail.gmail.com
Files
| Path | Change | +/− |
|---|---|---|
| src/backend/replication/logical/slotsync.c | modified | +12 −3 |
Discussion
- Fix race in ReplicationSlotRelease for ephemeral slots 29 messages · 2026-05-27 → 2026-07-02