Further corrections from the department of redundancy department.

Thom Brown

diff --git a/src/backend/storage/freespace/README b/src/backend/storage/freespace/README
index d591cbb5856f9ebc0783e17f00c258414dd17fbb..9732ad54d3ef237fe076791866bb04c2bd013c5a 100644 (file)
--- a/src/backend/storage/freespace/README
+++ b/src/backend/storage/freespace/README
@@ -125,7 +125,7 @@ we get a disk layout like this:
 where the numbers are page numbers *at that level*, starting from 0.
 
 To find the physical block # corresponding to leaf page n, we need to
-count the number number of leaf and upper-level pages preceding page n.
+count the number of leaf and upper-level pages preceding page n.
 This turns out to be
 
 y = n + (n / F + 1) + (n / F^2 + 1) + ... + 1

diff --git a/src/backend/storage/ipc/standby.c b/src/backend/storage/ipc/standby.c
index 845a839e67f27cda099f83437bdf76ec10d80f05..3a6831cab0c30129e31d63b2c947241f4d96fb61 100644 (file)
--- a/src/backend/storage/ipc/standby.c
+++ b/src/backend/storage/ipc/standby.c
@@ -1009,7 +1009,7 @@ LogAccessExclusiveLockPrepare(void)
         * RecordTransactionAbort() do not optimise away the transaction
         * completion record which recovery relies upon to release locks. It's a
         * hack, but for a corner case not worth adding code for into the main
-        * commit path. Second, must must assign an xid before the lock is
+        * commit path. Second, we must assign an xid before the lock is
         * recorded in shared memory, otherwise a concurrently executing
         * GetRunningTransactionLocks() might see a lock associated with an
         * InvalidTransactionId which we later assert cannot happen.

diff --git a/src/backend/storage/lmgr/README.barrier b/src/backend/storage/lmgr/README.barrier
index f9f3593b778f152bd35806c0832625a5c1fd67ec..4e37a4acbe7a77c3c20977bf20fdc58f9c4b98c5 100644 (file)
--- a/src/backend/storage/lmgr/README.barrier
+++ b/src/backend/storage/lmgr/README.barrier
@@ -128,7 +128,7 @@ And the reader can do this:
 
 On machines with strong memory ordering, these weaker barriers will simply
 prevent compiler rearrangement, without emitting any actual machine code.
-On machines with weak memory ordering, they will will prevent compiler
+On machines with weak memory ordering, they will prevent compiler
 reordering and also emit whatever hardware barrier may be required.  Even
 on machines with weak memory ordering, a read or write barrier may be able
 to use a less expensive instruction than a full barrier.