]> granicus.if.org Git - postgresql/commit
Fix race condition during replication origin drop.
authorTom Lane <tgl@sss.pgh.pa.us>
Tue, 9 Jan 2018 17:09:30 +0000 (12:09 -0500)
committerTom Lane <tgl@sss.pgh.pa.us>
Tue, 9 Jan 2018 17:09:30 +0000 (12:09 -0500)
commit1f5adbd799cf5bf98259003840c69c65c6b021db
tree80615aab7f83a28c5de9f5ce1cdae883a4cd8376
parent4af2190eb04b6a9160f2820e00802eabc78b4b1c
Fix race condition during replication origin drop.

replorigin_drop() misunderstood the API for condition variables: it
had ConditionVariablePrepareToSleep and ConditionVariableCancelSleep
inside its test-and-sleep loop, rather than outside the loop as
intended.  The net effect is a narrow race-condition window wherein,
if the process using a replication slot releases it immediately after
replorigin_drop() releases the ReplicationOriginLock, replorigin_drop()
would get into the condition variable's wait list too late and then
wait indefinitely for a signal that won't come.

Because there's a different CV for each replication slot, we can't
just move the ConditionVariablePrepareToSleep call to above the
test-and-sleep loop.  What we can do, in the wake of commit 13db3b936,
is drop the ConditionVariablePrepareToSleep call entirely.  This fix
depends on that commit because (at least in principle) the slot matching
the target replication origin might move around, so that once in a blue
moon successive loop iterations might involve different CVs.  We can now
cope with such a scenario, at the cost of an extra trip through the
retry loop.

(There are ways we could fix this bug without depending on that commit,
but they're all a lot more complicated than this way.)

While at it, upgrade the rather skimpy comments in this function.

Back-patch to v10 where this code came in.

Discussion: https://postgr.es/m/19947.1515455433@sss.pgh.pa.us
src/backend/replication/logical/origin.c