Avoid stale slot access after dropping obsolete synced slots. drop_local_obsolete_slots() continued to dereference local_slot after calling ReplicationSlotDropAcquired(). Once the slot is dropped, its entry in the slot array can be reused by another backend, so later reads of local_slot->data could observe a different slot's name or database OID, leading to an incorrect unlock and log message.
Save the slot name and database OID before performing the drop, and use the saved values for the subsequent UnlockSharedObject() call and the log message. While at it, emit the "dropped replication slot" message only when a slot was actually dropped, rather than unconditionally. Author: Xuneng Zhou <[email protected]> Reviewed-by: Zhijie Hou <[email protected]> Reviewed-by: Amit Kapila <[email protected]> Reviewed-by: Fujii Masao <[email protected]> Backpatch-through: 17, where it was introduced Discussion: https://postgr.es/m/ty4pr01mb177184ff9ee916f577e1f554194...@ty4pr01mb17718.jpnprd01.prod.outlook.com Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/08458bcaea5bc893c6150cc86adbac259a5d7b36 Modified Files -------------- src/backend/replication/logical/slotsync.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
