1
0
mirror of https://github.com/postgres/postgres.git synced 2025-11-28 11:44:57 +03:00

Copyedit comments and documentation.

This commit is contained in:
Noah Misch
2016-04-01 21:53:10 -04:00
parent f07d18b6e9
commit 4ad6f13500
17 changed files with 25 additions and 25 deletions

View File

@@ -89,12 +89,12 @@ then returns false, while LockBufferForCleanup() releases the exclusive lock
(but not the caller's pin) and waits until signaled by another backend,
whereupon it tries again. The signal will occur when UnpinBuffer decrements
the shared pin count to 1. As indicated above, this operation might have to
wait a good while before it acquires lock, but that shouldn't matter much for
concurrent VACUUM. The current implementation only supports a single waiter
for pin-count-1 on any particular shared buffer. This is enough for VACUUM's
use, since we don't allow multiple VACUUMs concurrently on a single relation
anyway. Anyone wishing to obtain a cleanup lock outside of recovery or a
VACUUM must use the conditional variant of the function.
wait a good while before it acquires the lock, but that shouldn't matter much
for concurrent VACUUM. The current implementation only supports a single
waiter for pin-count-1 on any particular shared buffer. This is enough for
VACUUM's use, since we don't allow multiple VACUUMs concurrently on a single
relation anyway. Anyone wishing to obtain a cleanup lock outside of recovery
or a VACUUM must use the conditional variant of the function.
Buffer Manager's Internal Locking

View File

@@ -921,7 +921,7 @@ ReadBuffer_common(SMgrRelation smgr, char relpersistence, ForkNumber forkNum,
*
* Since no-one else can be looking at the page contents yet, there is no
* difference between an exclusive lock and a cleanup-strength lock. (Note
* that we cannot use LockBuffer() of LockBufferForCleanup() here, because
* that we cannot use LockBuffer() or LockBufferForCleanup() here, because
* they assert that the buffer is already valid.)
*/
if ((mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK) &&
@@ -1882,7 +1882,7 @@ BufferSync(int flags)
* and clears the flag right after we check, but that doesn't matter
* since SyncOneBuffer will then do nothing. However, there is a
* further race condition: it's conceivable that between the time we
* examine the bit here and the time SyncOneBuffer acquires lock,
* examine the bit here and the time SyncOneBuffer acquires the lock,
* someone else not only wrote the buffer but replaced it with another
* page and dirtied it. In that improbable case, SyncOneBuffer will
* write the buffer though we didn't need to. It doesn't seem worth

View File

@@ -393,7 +393,7 @@ fsm_space_needed_to_cat(Size needed)
}
/*
* Returns the physical block number an FSM page
* Returns the physical block number of a FSM page
*/
static BlockNumber
fsm_logical_to_physical(FSMAddress addr)
@@ -472,7 +472,7 @@ fsm_get_parent(FSMAddress child, uint16 *slot)
}
/*
* Given a logical address of a parent page, and a slot number get the
* Given a logical address of a parent page and a slot number, get the
* logical address of the corresponding child page.
*/
static FSMAddress

View File

@@ -2673,7 +2673,7 @@ MinimumActiveBackends(int min)
/*
* Since we're not holding a lock, need to be prepared to deal with
* garbage, as someone could have incremented numPucs but not yet
* garbage, as someone could have incremented numProcs but not yet
* filled the structure.
*
* If someone just decremented numProcs, 'proc' could also point to a

View File

@@ -496,8 +496,8 @@ SerializationNeededForRead(Relation relation, Snapshot snapshot)
* Don't acquire locks or conflict when scanning with a special snapshot.
* This excludes things like CLUSTER and REINDEX. They use the wholesale
* functions TransferPredicateLocksToHeapRelation() and
* CheckTableForSerializableConflictIn() to participate serialization, but
* the scans involved don't need serialization.
* CheckTableForSerializableConflictIn() to participate in serialization,
* but the scans involved don't need serialization.
*/
if (!IsMVCCSnapshot(snapshot))
return false;

View File

@@ -901,7 +901,7 @@ mdnblocks(SMgrRelation reln, ForkNumber forknum)
* We used to pass O_CREAT here, but that's has the disadvantage
* that it might create a segment which has vanished through some
* operating system misadventure. In such a case, creating the
* segment here undermine _mdfd_getseg's attempts to notice and
* segment here undermines _mdfd_getseg's attempts to notice and
* report an error upon access to a missing segment.
*/
v->mdfd_chain = _mdfd_openseg(reln, forknum, segno, 0);