From 1b4998fd44bad9f8ab90e741cadd6519f6c94a44 Mon Sep 17 00:00:00 2001 From: Robert Haas <rhaas@postgresql.org> Date: Wed, 2 May 2012 11:11:25 -0400 Subject: [PATCH] Further corrections from the department of redundancy department. Thom Brown --- src/backend/storage/freespace/README | 2 +- src/backend/storage/ipc/standby.c | 2 +- src/backend/storage/lmgr/README.barrier | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff --git a/src/backend/storage/freespace/README b/src/backend/storage/freespace/README index d591cbb5856..9732ad54d3e 100644 --- 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 845a839e67f..3a6831cab0c 100644 --- 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 f9f3593b778..4e37a4acbe7 100644 --- 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. -- GitLab