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@example.com) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers