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 ------ master Details ------- https://git.postgresql.org/pg/commitdiff/bdae2c20e88d80c63bd8de2c57aebd9cea590bc7 Modified Files -------------- src/backend/replication/logical/slotsync.c | 23 +++++++++++++---------- 1 file changed, 13 insertions(+), 10 deletions(-)
