Further corrections from the department of redundancy department.

robertmhaas · robertmhaas · commit 1b4998fd44ba · 2012-05-02T11:11:25.000-04:00
Thom Brown
diff --git 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
@@ -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
@@ -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.
