Fix typos in comments.
Thom Brown
This commit is contained in:
parent
5c6d9fc4b2
commit
2bccced110
@ -429,7 +429,7 @@ bf_init(PX_Cipher *c, const uint8 *key, unsigned klen, const uint8 *iv)
|
||||
|
||||
/*
|
||||
* Test if key len is supported. BF_set_key silently cut large keys and it
|
||||
* could be be a problem when user transfer crypted data from one server
|
||||
* could be a problem when user transfer crypted data from one server
|
||||
* to another.
|
||||
*/
|
||||
|
||||
|
@ -270,7 +270,7 @@
|
||||
contains the corresponding query keys. Likewise, the function must
|
||||
return GIN_FALSE only if the item does not match, whether or not it
|
||||
contains the GIN_MAYBE keys. If the result depends on the GIN_MAYBE
|
||||
entries, ie. the match cannot be confirmed or refuted based on the
|
||||
entries, i.e. the match cannot be confirmed or refuted based on the
|
||||
known query keys, the function must return GIN_MAYBE.
|
||||
</para>
|
||||
<para>
|
||||
|
@ -933,7 +933,7 @@ keyGetItem(GinState *ginstate, MemoryContext tempCtx, GinScanKey key,
|
||||
/*
|
||||
* Ok, we now know that there are no matches < minItem.
|
||||
*
|
||||
* If minItem is lossy, it means that there there were no exact items on
|
||||
* If minItem is lossy, it means that there were no exact items on
|
||||
* the page among requiredEntries, because lossy pointers sort after exact
|
||||
* items. However, there might be exact items for the same page among
|
||||
* additionalEntries, so we mustn't advance past them.
|
||||
|
@ -10,7 +10,7 @@
|
||||
* a GIN scan can apply various optimizations, if it can determine that an
|
||||
* item matches or doesn't match, even if it doesn't know if some of the keys
|
||||
* are present or not. Hence, it's useful to have a ternary-logic consistent
|
||||
* function, where where each key can be TRUE (present), FALSE (not present),
|
||||
* function, where each key can be TRUE (present), FALSE (not present),
|
||||
* or MAYBE (don't know if present). This file provides such a ternary-logic
|
||||
* consistent function, implemented by calling the regular boolean consistent
|
||||
* function many times, with all the MAYBE arguments set to all combinations
|
||||
|
@ -783,9 +783,9 @@ raw_heap_insert(RewriteState state, HeapTuple tup)
|
||||
* deal with WAL logging at all - an fsync() at the end of a rewrite would be
|
||||
* sufficient for crash safety. Any mapping that hasn't been safely flushed to
|
||||
* disk has to be by an aborted (explicitly or via a crash) transaction and is
|
||||
* ignored by virtue of the xid in it's name being subject to a
|
||||
* ignored by virtue of the xid in its name being subject to a
|
||||
* TransactionDidCommit() check. But we want to support having standbys via
|
||||
* physical replication, both for availability and to to do logical decoding
|
||||
* physical replication, both for availability and to do logical decoding
|
||||
* there.
|
||||
* ------------------------------------------------------------------------
|
||||
*/
|
||||
@ -1046,7 +1046,7 @@ logical_rewrite_log_mapping(RewriteState state, TransactionId xid,
|
||||
|
||||
/*
|
||||
* Perform logical remapping for a tuple that's mapped from old_tid to
|
||||
* new_tuple->t_self by rewrite_heap_tuple() iff necessary for the tuple.
|
||||
* new_tuple->t_self by rewrite_heap_tuple() if necessary for the tuple.
|
||||
*/
|
||||
static void
|
||||
logical_rewrite_heap_tuple(RewriteState state, ItemPointerData old_tid,
|
||||
|
@ -26,7 +26,7 @@
|
||||
/*
|
||||
* Delete 'node' from list.
|
||||
*
|
||||
* It is not allowed to delete a 'node' which is is not in the list 'head'
|
||||
* It is not allowed to delete a 'node' which is not in the list 'head'
|
||||
*
|
||||
* Caution: this is O(n); consider using slist_delete_current() instead.
|
||||
*/
|
||||
|
@ -293,7 +293,7 @@ CreateInitDecodingContext(char *plugin,
|
||||
* So we have to acquire the ProcArrayLock to prevent computation of new
|
||||
* xmin horizons by other backends, get the safe decoding xid, and inform
|
||||
* the slot machinery about the new limit. Once that's done the
|
||||
* ProcArrayLock can be be released as the slot machinery now is
|
||||
* ProcArrayLock can be released as the slot machinery now is
|
||||
* protecting against vacuum.
|
||||
* ----
|
||||
*/
|
||||
|
@ -55,7 +55,7 @@
|
||||
*
|
||||
*
|
||||
*
|
||||
* The snapbuild machinery is starting up in in several stages, as illustrated
|
||||
* The snapbuild machinery is starting up in several stages, as illustrated
|
||||
* by the following graph:
|
||||
* +-------------------------+
|
||||
* +----|SNAPBUILD_START |-------------+
|
||||
@ -779,7 +779,7 @@ SnapBuildDistributeNewCatalogSnapshot(SnapBuild *builder, XLogRecPtr lsn)
|
||||
/*
|
||||
* If we don't have a base snapshot yet, there are no changes in this
|
||||
* transaction which in turn implies we don't yet need a snapshot at
|
||||
* all. We'll add add a snapshot when the first change gets queued.
|
||||
* all. We'll add a snapshot when the first change gets queued.
|
||||
*
|
||||
* NB: This works correctly even for subtransactions because
|
||||
* ReorderBufferCommitChild() takes care to pass the parent the base
|
||||
|
@ -2343,7 +2343,7 @@ relation_is_updatable(Oid reloid,
|
||||
|
||||
/*
|
||||
* Determine which of the view's columns are updatable. If there
|
||||
* are none within the set of of columns we are looking at, then
|
||||
* are none within the set of columns we are looking at, then
|
||||
* the view doesn't support INSERT/UPDATE, but it may still
|
||||
* support DELETE.
|
||||
*/
|
||||
|
@ -395,7 +395,7 @@ parse_object(JsonLexContext *lex, JsonSemAction *sem)
|
||||
(*ostart) (sem->semstate);
|
||||
|
||||
/*
|
||||
* Data inside an object at at a higher nesting level than the object
|
||||
* Data inside an object is at a higher nesting level than the object
|
||||
* itself. Note that we increment this after we call the semantic routine
|
||||
* for the object start and restore it before we call the routine for the
|
||||
* object end.
|
||||
@ -473,7 +473,7 @@ parse_array(JsonLexContext *lex, JsonSemAction *sem)
|
||||
(*astart) (sem->semstate);
|
||||
|
||||
/*
|
||||
* Data inside an array at at a higher nesting level than the array
|
||||
* Data inside an array is at a higher nesting level than the array
|
||||
* itself. Note that we increment this after we call the semantic routine
|
||||
* for the array start and restore it before we call the routine for the
|
||||
* array end.
|
||||
|
@ -1549,7 +1549,7 @@ HeapTupleHeaderIsOnlyLocked(HeapTupleHeader tuple)
|
||||
}
|
||||
|
||||
/*
|
||||
* check whether the transaciont id 'xid' in in the pre-sorted array 'xip'.
|
||||
* check whether the transaciont id 'xid' is in the pre-sorted array 'xip'.
|
||||
*/
|
||||
static bool
|
||||
TransactionIdInArray(TransactionId xid, TransactionId *xip, Size num)
|
||||
@ -1589,7 +1589,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
|
||||
Assert(!TransactionIdDidCommit(xmin));
|
||||
return false;
|
||||
}
|
||||
/* check if its one of our txids, toplevel is also in there */
|
||||
/* check if it's one of our txids, toplevel is also in there */
|
||||
else if (TransactionIdInArray(xmin, snapshot->subxip, snapshot->subxcnt))
|
||||
{
|
||||
bool resolved;
|
||||
@ -1598,7 +1598,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
|
||||
|
||||
/*
|
||||
* another transaction might have (tried to) delete this tuple or
|
||||
* cmin/cmax was stored in a combocid. S we need to to lookup the
|
||||
* cmin/cmax was stored in a combocid. So we need to lookup the
|
||||
* actual values externally.
|
||||
*/
|
||||
resolved = ResolveCminCmaxDuringDecoding(HistoricSnapshotGetTupleCids(), snapshot,
|
||||
@ -1662,7 +1662,7 @@ HeapTupleSatisfiesHistoricMVCC(HeapTuple htup, Snapshot snapshot,
|
||||
xmax = HeapTupleGetUpdateXid(tuple);
|
||||
}
|
||||
|
||||
/* check if its one of our txids, toplevel is also in there */
|
||||
/* check if it's one of our txids, toplevel is also in there */
|
||||
if (TransactionIdInArray(xmax, snapshot->subxip, snapshot->subxcnt))
|
||||
{
|
||||
bool resolved;
|
||||
|
Loading…
x
Reference in New Issue
Block a user