Hello,
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.
--
Julien Rouhaud
http://dalibo.com - http://dalibo.org
diff --git a/src/backend/replication/syncrep.c
b/src/backend/replication/syncrep.c
index 67249d8..c3e11b8 100644
--- a/src/backend/replication/syncrep.c
+++ b/src/backend/replication/syncrep.c
@@ -195,17 +195,12 @@ SyncRepWaitForLSN(XLogRecPtr lsn, bool commit)
ResetLatch(MyLatch);
/*
- * Try checking the state without the lock first. There's no
- * guarantee that we'll read the most up-to-date value, so if
it looks
- * like we're still waiting, recheck while holding the lock.
But if
- * it looks like we're done, we must really be done, because
once
- * walsender changes the state to SYNC_REP_WAIT_COMPLETE, it
will
- * never update it again, so we can't be seeing a stale value
in that
- * case.
+ * Acquiring the lock is not needed, the latch ensure proper
barriers.
+ * If it looks like we're done, we must really be done, because
once
+ * walsender changes the state to SYNC_REP_WAIT_COMPLETE, it
will never
+ * update it again, so we can't be seeing a stale value in that
case.
*/
syncRepState = MyProc->syncRepState;
- if (syncRepState == SYNC_REP_WAITING)
- syncRepState = MyProc->syncRepState;
if (syncRepState == SYNC_REP_WAIT_COMPLETE)
break;
--
Sent via pgsql-hackers mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
