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 <[email protected]> Author: Xuneng Zhou <[email protected]> Author: Amit Kapila <[email protected]> Discussion: https://postgr.es/m/CAHGQGwGGyEDL3dh7uJ6qPsGvnq4QK_R8+U=12caprnzwrwa...@mail.gmail.com Discussion: https://postgr.es/m/cahgqgwhqq1ppvffykvxlfryc-byrdwsn0neahj9slyv97oo...@mail.gmail.com Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/6b41bd1a459cb457cbb51d021b70004646d78db0 Modified Files -------------- src/backend/replication/logical/slotsync.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-)
