Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot()
authorMichael Paquier <michael@paquier.xyz>
Tue, 20 Feb 2024 04:43:51 +0000 (13:43 +0900)
committerMichael Paquier <michael@paquier.xyz>
Tue, 20 Feb 2024 04:43:51 +0000 (13:43 +0900)
commit818fefd8fd4412d45eb542155cb2833a2b864acc
treeaee58e95702240630654c8a9e087968f94ca5eae
parent01ec4d89b91ed4c0cad57b188b530b9e7980ccb5
Fix race leading to incorrect conflict cause in InvalidatePossiblyObsoleteSlot()

The invalidation of an active slot is done in two steps:
- Termination of the backend holding it, if any.
- Report that the slot is obsolete, with a conflict cause depending on
the slot's data.

This can be racy because between these two steps the slot mutex would be
released while doing system calls, which means that the effective_xmin
and effective_catalog_xmin could advance during that time, detecting a
conflict cause different than the one originally wanted before the
process owning a slot is terminated.

Holding the mutex longer is not an option, so this commit changes the
code to record the LSNs stored in the slot during the termination of the
process owning the slot.

Bonus thanks to Alexander Lakhin for the various tests and the analysis.

Author: Bertrand Drouvot
Reviewed-by: Michael Paquier, Bharath Rupireddy
Discussion: https://postgr.es/m/ZaTjW2Xh+TQUCOH0@ip-10-97-1-34.eu-west-3.compute.internal
Backpatch-through: 16
src/backend/replication/slot.c