Fix out-of-date version reference, grammar.
authorAndres Freund <andres@anarazel.de>
Thu, 13 Aug 2020 00:04:51 +0000 (17:04 -0700)
committerAndres Freund <andres@anarazel.de>
Thu, 13 Aug 2020 00:04:51 +0000 (17:04 -0700)
Time appears to be passing fast.

Reported-By: Peter Geoghegan <pg@bowt.ie>
src/backend/access/nbtree/README
src/backend/access/transam/README

index 781a8f1932d3a159b230e479cda3e9e8685f714d..9692e4cdf64419e6f5ceb58b46bbeb192295d64a 100644 (file)
@@ -412,7 +412,7 @@ the cost of walking down the tree in such common cases.
 
 The optimization works on the assumption that there can only be one
 non-ignorable leaf rightmost page, and so not even a visible-to-everyone
-style interlock required.  We cannot fail to detect that our hint was
+style interlock is required.  We cannot fail to detect that our hint was
 invalidated, because there can only be one such page in the B-Tree at
 any time. It's possible that the page will be deleted and recycled
 without a backend's cached page also being detected as invalidated, but
index 6f44ae9ce6a50e702880e9c47dad2fab167e7557..98acb429b67e4e71f2293f455e412bc73e277ee4 100644 (file)
@@ -318,7 +318,7 @@ XID less than this could be about to appear in the ProcArray, because of the
 XidGenLock interlock discussed above.)
 
 As GetSnapshotData is performance critical, it does not perform an accurate
-oldest-xmin calculation (it used to, until v13). The contents of a snapshot
+oldest-xmin calculation (it used to, until v14). The contents of a snapshot
 only depend on the xids of other backends, not their xmin. As backend's xmin
 changes much more often than its xid, having GetSnapshotData look at xmins
 can lead to a lot of unnecessary cacheline ping-pong.  Instead