Since 14e8803f1, it's not necessary to acquire the SyncRepLock to see up
to date data. But it looks like this commit didn't update all the
comment around MyProc->syncRepState, which still mention retrieving the
value without and without lock. Also, there's I think a now unneeded
test to try to retrieve again syncRepState.
Patch attached to fix both small issues, present since 9.5.
http://dalibo.com - http://dalibo.org
diff --git a/src/backend/replication/syncrep.c
index 67249d8..c3e11b8 100644
@@ -195,17 +195,12 @@ SyncRepWaitForLSN(XLogRecPtr lsn, bool commit)
- * Try checking the state without the lock first. There's no
- * guarantee that we'll read the most up-to-date value, so if
- * like we're still waiting, recheck while holding the lock.
- * it looks like we're done, we must really be done, because
- * walsender changes the state to SYNC_REP_WAIT_COMPLETE, it
- * never update it again, so we can't be seeing a stale value
- * case.
+ * Acquiring the lock is not needed, the latch ensure proper
+ * If it looks like we're done, we must really be done, because
+ * walsender changes the state to SYNC_REP_WAIT_COMPLETE, it
+ * update it again, so we can't be seeing a stale value in that
syncRepState = MyProc->syncRepState;
- if (syncRepState == SYNC_REP_WAITING)
- syncRepState = MyProc->syncRepState;
if (syncRepState == SYNC_REP_WAIT_COMPLETE)
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: