diff options
Diffstat (limited to 'src/backend/access/heap')
| -rw-r--r-- | src/backend/access/heap/heapam.c | 120 | ||||
| -rw-r--r-- | src/backend/access/heap/hio.c | 20 | ||||
| -rw-r--r-- | src/backend/access/heap/pruneheap.c | 12 | ||||
| -rw-r--r-- | src/backend/access/heap/rewriteheap.c | 14 | ||||
| -rw-r--r-- | src/backend/access/heap/syncscan.c | 6 | ||||
| -rw-r--r-- | src/backend/access/heap/tuptoaster.c | 10 | ||||
| -rw-r--r-- | src/backend/access/heap/visibilitymap.c | 20 |
7 files changed, 101 insertions, 101 deletions
diff --git a/src/backend/access/heap/heapam.c b/src/backend/access/heap/heapam.c index a8653e4a96c..ccdcb5be2a2 100644 --- a/src/backend/access/heap/heapam.c +++ b/src/backend/access/heap/heapam.c @@ -207,7 +207,7 @@ initscan(HeapScanDesc scan, ScanKey key, bool is_rescan) * while the scan is in progress will be invisible to my snapshot anyway. * (That is not true when using a non-MVCC snapshot. However, we couldn't * guarantee to return tuples added after scan start anyway, since they - * might go into pages we already scanned. To guarantee consistent + * might go into pages we already scanned. To guarantee consistent * results for a non-MVCC snapshot, the caller must hold some higher-level * lock that ensures the interesting tuple(s) won't change.) */ @@ -215,7 +215,7 @@ initscan(HeapScanDesc scan, ScanKey key, bool is_rescan) /* * If the table is large relative to NBuffers, use a bulk-read access - * strategy and enable synchronized scanning (see syncscan.c). Although + * strategy and enable synchronized scanning (see syncscan.c). Although * the thresholds for these features could be different, we make them the * same so that there are only two behaviors to tune rather than four. * (However, some callers need to be able to disable one or both of these @@ -319,7 +319,7 @@ heapgetpage(HeapScanDesc scan, BlockNumber page) } /* - * Be sure to check for interrupts at least once per page. Checks at + * Be sure to check for interrupts at least once per page. Checks at * higher code levels won't be able to stop a seqscan that encounters many * pages' worth of consecutive dead tuples. */ @@ -344,7 +344,7 @@ heapgetpage(HeapScanDesc scan, BlockNumber page) /* * We must hold share lock on the buffer content while examining tuple - * visibility. Afterwards, however, the tuples we have found to be + * visibility. Afterwards, however, the tuples we have found to be * visible are guaranteed good as long as we hold the buffer pin. */ LockBuffer(buffer, BUFFER_LOCK_SHARE); @@ -1120,7 +1120,7 @@ relation_openrv(const RangeVar *relation, LOCKMODE lockmode) * * Same as relation_openrv, but with an additional missing_ok argument * allowing a NULL return rather than an error if the relation is not - * found. (Note that some other causes, such as permissions problems, + * found. (Note that some other causes, such as permissions problems, * will still result in an ereport.) * ---------------- */ @@ -1720,7 +1720,7 @@ heap_hot_search_buffer(ItemPointer tid, Relation relation, Buffer buffer, /* * When first_call is true (and thus, skip is initially false) we'll - * return the first tuple we find. But on later passes, heapTuple + * return the first tuple we find. But on later passes, heapTuple * will initially be pointing to the tuple we returned last time. * Returning it again would be incorrect (and would loop forever), so * we skip it and return the next match we find. @@ -1802,7 +1802,7 @@ heap_hot_search(ItemPointer tid, Relation relation, Snapshot snapshot, * possibly uncommitted version. * * *tid is both an input and an output parameter: it is updated to - * show the latest version of the row. Note that it will not be changed + * show the latest version of the row. Note that it will not be changed * if no version of the row passes the snapshot test. */ void @@ -1922,7 +1922,7 @@ heap_get_latest_tid(Relation relation, * * This is called after we have waited for the XMAX transaction to terminate. * If the transaction aborted, we guarantee the XMAX_INVALID hint bit will - * be set on exit. If the transaction committed, we set the XMAX_COMMITTED + * be set on exit. If the transaction committed, we set the XMAX_COMMITTED * hint bit if possible --- but beware that that may not yet be possible, * if the transaction committed asynchronously. * @@ -2009,7 +2009,7 @@ FreeBulkInsertState(BulkInsertState bistate) * The return value is the OID assigned to the tuple (either here or by the * caller), or InvalidOid if no OID. The header fields of *tup are updated * to match the stored tuple; in particular tup->t_self receives the actual - * TID where the tuple was stored. But note that any toasting of fields + * TID where the tuple was stored. But note that any toasting of fields * within the tuple data is NOT reflected into *tup. */ Oid @@ -2038,7 +2038,7 @@ heap_insert(Relation relation, HeapTuple tup, CommandId cid, * For a heap insert, we only need to check for table-level SSI locks. Our * new tuple can't possibly conflict with existing tuple locks, and heap * page locks are only consolidated versions of tuple locks; they do not - * lock "gaps" as index page locks do. So we don't need to identify a + * lock "gaps" as index page locks do. So we don't need to identify a * buffer before making the call. */ CheckForSerializableConflictIn(relation, NULL, InvalidBuffer); @@ -2184,7 +2184,7 @@ heap_prepare_insert(Relation relation, HeapTuple tup, TransactionId xid, /* * If the object id of this tuple has already been assigned, trust the - * caller. There are a couple of ways this can happen. At initial db + * caller. There are a couple of ways this can happen. At initial db * creation, the backend program sets oids for tuples. When we define * an index, we set the oid. Finally, in the future, we may allow * users to set their own object ids in order to support a persistent @@ -2279,7 +2279,7 @@ heap_multi_insert(Relation relation, HeapTuple *tuples, int ntuples, * For a heap insert, we only need to check for table-level SSI locks. Our * new tuple can't possibly conflict with existing tuple locks, and heap * page locks are only consolidated versions of tuple locks; they do not - * lock "gaps" as index page locks do. So we don't need to identify a + * lock "gaps" as index page locks do. So we don't need to identify a * buffer before making the call. */ CheckForSerializableConflictIn(relation, NULL, InvalidBuffer); @@ -2293,7 +2293,7 @@ heap_multi_insert(Relation relation, HeapTuple *tuples, int ntuples, int nthispage; /* - * Find buffer where at least the next tuple will fit. If the page is + * Find buffer where at least the next tuple will fit. If the page is * all-visible, this will also pin the requisite visibility map page. */ buffer = RelationGetBufferForTuple(relation, heaptuples[ndone]->t_len, @@ -2660,10 +2660,10 @@ l1: /* * You might think the multixact is necessarily done here, but not * so: it could have surviving members, namely our own xact or - * other subxacts of this backend. It is legal for us to delete + * other subxacts of this backend. It is legal for us to delete * the tuple in either case, however (the latter case is * essentially a situation of upgrading our former shared lock to - * exclusive). We don't bother changing the on-disk hint bits + * exclusive). We don't bother changing the on-disk hint bits * since we are about to overwrite the xmax altogether. */ } @@ -2739,7 +2739,7 @@ l1: * If this is the first possibly-multixact-able operation in the current * transaction, set my per-backend OldestMemberMXactId setting. We can be * certain that the transaction will never become a member of any older - * MultiXactIds than that. (We have to do this even if we end up just + * MultiXactIds than that. (We have to do this even if we end up just * using our own TransactionId below, since some other backend could * incorporate our XID into a MultiXact immediately afterwards.) */ @@ -2755,7 +2755,7 @@ l1: /* * If this transaction commits, the tuple will become DEAD sooner or * later. Set flag that this page is a candidate for pruning once our xid - * falls below the OldestXmin horizon. If the transaction finally aborts, + * falls below the OldestXmin horizon. If the transaction finally aborts, * the subsequent page pruning will be a no-op and the hint will be * cleared. */ @@ -2859,7 +2859,7 @@ l1: * * This routine may be used to delete a tuple when concurrent updates of * the target tuple are not expected (for example, because we have a lock - * on the relation associated with the tuple). Any failure is reported + * on the relation associated with the tuple). Any failure is reported * via ereport(). */ void @@ -2971,7 +2971,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup, /* * Fetch the list of attributes to be checked for HOT update. This is * wasted effort if we fail to update or have to put the new tuple on a - * different page. But we must compute the list before obtaining buffer + * different page. But we must compute the list before obtaining buffer * lock --- in the worst case, if we are doing an update on one of the * relevant system catalogs, we could deadlock if we try to fetch the list * later. In any case, the relcache caches the data so this is usually @@ -3052,7 +3052,7 @@ heap_update(Relation relation, ItemPointer otid, HeapTuple newtup, * If this is the first possibly-multixact-able operation in the * current transaction, set my per-backend OldestMemberMXactId * setting. We can be certain that the transaction will never become a - * member of any older MultiXactIds than that. (We have to do this + * member of any older MultiXactIds than that. (We have to do this * even if we end up just using our own TransactionId below, since * some other backend could incorporate our XID into a MultiXact * immediately afterwards.) @@ -3097,7 +3097,7 @@ l2: /* * XXX note that we don't consider the "no wait" case here. This * isn't a problem currently because no caller uses that case, but it - * should be fixed if such a caller is introduced. It wasn't a + * should be fixed if such a caller is introduced. It wasn't a * problem previously because this code would always wait, but now * that some tuple locks do not conflict with one of the lock modes we * use, it is possible that this case is interesting to handle @@ -3135,7 +3135,7 @@ l2: * it as locker, unless it is gone completely. * * If it's not a multi, we need to check for sleeping conditions - * before actually going to sleep. If the update doesn't conflict + * before actually going to sleep. If the update doesn't conflict * with the locks, we just continue without sleeping (but making sure * it is preserved). */ @@ -3160,10 +3160,10 @@ l2: goto l2; /* - * Note that the multixact may not be done by now. It could have + * Note that the multixact may not be done by now. It could have * surviving members; our own xact or other subxacts of this * backend, and also any other concurrent transaction that locked - * the tuple with KeyShare if we only got TupleLockUpdate. If + * the tuple with KeyShare if we only got TupleLockUpdate. If * this is the case, we have to be careful to mark the updated * tuple with the surviving members in Xmax. * @@ -3369,7 +3369,7 @@ l2: * If the toaster needs to be activated, OR if the new tuple will not fit * on the same page as the old, then we need to release the content lock * (but not the pin!) on the old tuple's buffer while we are off doing - * TOAST and/or table-file-extension work. We must mark the old tuple to + * TOAST and/or table-file-extension work. We must mark the old tuple to * show that it's already being updated, else other processes may try to * update it themselves. * @@ -3435,7 +3435,7 @@ l2: * there's more free now than before. * * What's more, if we need to get a new page, we will need to acquire - * buffer locks on both old and new pages. To avoid deadlock against + * buffer locks on both old and new pages. To avoid deadlock against * some other backend trying to get the same two locks in the other * order, we must be consistent about the order we get the locks in. * We use the rule "lock the lower-numbered page of the relation @@ -3495,7 +3495,7 @@ l2: /* * At this point newbuf and buffer are both pinned and locked, and newbuf - * has enough space for the new tuple. If they are the same buffer, only + * has enough space for the new tuple. If they are the same buffer, only * one pin is held. */ @@ -3503,7 +3503,7 @@ l2: { /* * Since the new tuple is going into the same page, we might be able - * to do a HOT update. Check if any of the index columns have been + * to do a HOT update. Check if any of the index columns have been * changed. If not, then HOT update is possible. */ if (satisfies_hot) @@ -3521,13 +3521,13 @@ l2: /* * If this transaction commits, the old tuple will become DEAD sooner or * later. Set flag that this page is a candidate for pruning once our xid - * falls below the OldestXmin horizon. If the transaction finally aborts, + * falls below the OldestXmin horizon. If the transaction finally aborts, * the subsequent page pruning will be a no-op and the hint will be * cleared. * * XXX Should we set hint on newbuf as well? If the transaction aborts, * there would be a prunable tuple in the newbuf; but for now we choose - * not to optimize for aborts. Note that heap_xlog_update must be kept in + * not to optimize for aborts. Note that heap_xlog_update must be kept in * sync if this decision changes. */ PageSetPrunable(page, xid); @@ -3612,7 +3612,7 @@ l2: * Mark old tuple for invalidation from system caches at next command * boundary, and mark the new tuple for invalidation in case we abort. We * have to do this before releasing the buffer because oldtup is in the - * buffer. (heaptup is all in local memory, but it's necessary to process + * buffer. (heaptup is all in local memory, but it's necessary to process * both tuple versions in one call to inval.c so we can avoid redundant * sinval messages.) */ @@ -3687,7 +3687,7 @@ heap_tuple_attr_equals(TupleDesc tupdesc, int attrnum, /* * Extract the corresponding values. XXX this is pretty inefficient if - * there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do + * there are many indexed columns. Should HeapSatisfiesHOTandKeyUpdate do * a single heap_deform_tuple call on each tuple, instead? But that * doesn't work for system columns ... */ @@ -3710,7 +3710,7 @@ heap_tuple_attr_equals(TupleDesc tupdesc, int attrnum, /* * We do simple binary comparison of the two datums. This may be overly * strict because there can be multiple binary representations for the - * same logical value. But we should be OK as long as there are no false + * same logical value. But we should be OK as long as there are no false * positives. Using a type-specific equality operator is messy because * there could be multiple notions of equality in different operator * classes; furthermore, we cannot safely invoke user-defined functions @@ -3832,7 +3832,7 @@ HeapSatisfiesHOTandKeyUpdate(Relation relation, * * This routine may be used to update a tuple when concurrent updates of * the target tuple are not expected (for example, because we have a lock - * on the relation associated with the tuple). Any failure is reported + * on the relation associated with the tuple). Any failure is reported * via ereport(). */ void @@ -4056,15 +4056,15 @@ l3: * However, if there are updates, we need to walk the update chain * to mark future versions of the row as locked, too. That way, * if somebody deletes that future version, we're protected - * against the key going away. This locking of future versions + * against the key going away. This locking of future versions * could block momentarily, if a concurrent transaction is * deleting a key; or it could return a value to the effect that - * the transaction deleting the key has already committed. So we + * the transaction deleting the key has already committed. So we * do this before re-locking the buffer; otherwise this would be * prone to deadlocks. * * Note that the TID we're locking was grabbed before we unlocked - * the buffer. For it to change while we're not looking, the + * the buffer. For it to change while we're not looking, the * other properties we're testing for below after re-locking the * buffer would also change, in which case we would restart this * loop above. @@ -4285,7 +4285,7 @@ l3: * Of course, the multixact might not be done here: if we're * requesting a light lock mode, other transactions with light * locks could still be alive, as well as locks owned by our - * own xact or other subxacts of this backend. We need to + * own xact or other subxacts of this backend. We need to * preserve the surviving MultiXact members. Note that it * isn't absolutely necessary in the latter case, but doing so * is simpler. @@ -4328,7 +4328,7 @@ l3: /* * xwait is done, but if xwait had just locked the tuple then * some other xact could update this tuple before we get to - * this point. Check for xmax change, and start over if so. + * this point. Check for xmax change, and start over if so. */ if (xmax_infomask_changed(tuple->t_data->t_infomask, infomask) || !TransactionIdEquals( @@ -4337,7 +4337,7 @@ l3: goto l3; /* - * Otherwise check if it committed or aborted. Note we cannot + * Otherwise check if it committed or aborted. Note we cannot * be here if the tuple was only locked by somebody who didn't * conflict with us; that should have been handled above. So * that transaction must necessarily be gone by now. @@ -4417,7 +4417,7 @@ failed: * If this is the first possibly-multixact-able operation in the current * transaction, set my per-backend OldestMemberMXactId setting. We can be * certain that the transaction will never become a member of any older - * MultiXactIds than that. (We have to do this even if we end up just + * MultiXactIds than that. (We have to do this even if we end up just * using our own TransactionId below, since some other backend could * incorporate our XID into a MultiXact immediately afterwards.) */ @@ -4453,7 +4453,7 @@ failed: HeapTupleHeaderSetXmax(tuple->t_data, xid); /* - * Make sure there is no forward chain link in t_ctid. Note that in the + * Make sure there is no forward chain link in t_ctid. Note that in the * cases where the tuple has been updated, we must not overwrite t_ctid, * because it was set by the updater. Moreover, if the tuple has been * updated, we need to follow the update chain to lock the new versions of @@ -4465,8 +4465,8 @@ failed: MarkBufferDirty(*buffer); /* - * XLOG stuff. You might think that we don't need an XLOG record because - * there is no state change worth restoring after a crash. You would be + * XLOG stuff. You might think that we don't need an XLOG record because + * there is no state change worth restoring after a crash. You would be * wrong however: we have just written either a TransactionId or a * MultiXactId that may never have been seen on disk before, and we need * to make sure that there are XLOG entries covering those ID numbers. @@ -4630,7 +4630,7 @@ l5: * If the XMAX is already a MultiXactId, then we need to expand it to * include add_to_xmax; but if all the members were lockers and are * all gone, we can do away with the IS_MULTI bit and just set - * add_to_xmax as the only locker/updater. If all lockers are gone + * add_to_xmax as the only locker/updater. If all lockers are gone * and we have an updater that aborted, we can also do without a * multi. * @@ -4712,8 +4712,8 @@ l5: { /* * LOCK_ONLY can be present alone only when a page has been - * upgraded by pg_upgrade. But in that case, - * TransactionIdIsInProgress() should have returned false. We + * upgraded by pg_upgrade. But in that case, + * TransactionIdIsInProgress() should have returned false. We * assume it's no longer locked in this case. */ elog(WARNING, "LOCK_ONLY found for Xid in progress %u", xmax); @@ -4871,7 +4871,7 @@ test_lockmode_for_conflict(MultiXactStatus status, TransactionId xid, * The other transaction committed. If it was only a locker, then the * lock is completely gone now and we can return success; but if it * was an update, then what we do depends on whether the two lock - * modes conflict. If they conflict, then we must report error to + * modes conflict. If they conflict, then we must report error to * caller. But if they don't, we can fall through to allow the current * transaction to lock the tuple. * @@ -5132,7 +5132,7 @@ l4: * The initial tuple is assumed to be already locked. * * This function doesn't check visibility, it just inconditionally marks the - * tuple(s) as locked. If any tuple in the updated chain is being deleted + * tuple(s) as locked. If any tuple in the updated chain is being deleted * concurrently (or updated with the key being modified), sleep until the * transaction doing it is finished. * @@ -5156,7 +5156,7 @@ heap_lock_updated_tuple(Relation rel, HeapTuple tuple, ItemPointer ctid, * If this is the first possibly-multixact-able operation in the * current transaction, set my per-backend OldestMemberMXactId * setting. We can be certain that the transaction will never become a - * member of any older MultiXactIds than that. (We have to do this + * member of any older MultiXactIds than that. (We have to do this * even if we end up just using our own TransactionId below, since * some other backend could incorporate our XID into a MultiXact * immediately afterwards.) @@ -5175,7 +5175,7 @@ heap_lock_updated_tuple(Relation rel, HeapTuple tuple, ItemPointer ctid, * heap_inplace_update - update a tuple "in place" (ie, overwrite it) * * Overwriting violates both MVCC and transactional safety, so the uses - * of this function in Postgres are extremely limited. Nonetheless we + * of this function in Postgres are extremely limited. Nonetheless we * find some places to use it. * * The tuple cannot change size, and therefore it's reasonable to assume @@ -5537,7 +5537,7 @@ FreezeMultiXactId(MultiXactId multi, uint16 t_infomask, * heap_prepare_freeze_tuple * * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac) - * are older than the specified cutoff XID and cutoff MultiXactId. If so, + * are older than the specified cutoff XID and cutoff MultiXactId. If so, * setup enough state (in the *frz output argument) to later execute and * WAL-log what we would need to do, and return TRUE. Return FALSE if nothing * is to be changed. @@ -5666,7 +5666,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid, /* * The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED + - * LOCKED. Normalize to INVALID just to be sure no one gets confused. + * LOCKED. Normalize to INVALID just to be sure no one gets confused. * Also get rid of the HEAP_KEYS_UPDATED bit. */ frz->t_infomask &= ~HEAP_XMAX_BITS; @@ -6040,7 +6040,7 @@ ConditionalMultiXactIdWait(MultiXactId multi, MultiXactStatus status, * heap_tuple_needs_freeze * * Check to see whether any of the XID fields of a tuple (xmin, xmax, xvac) - * are older than the specified cutoff XID or MultiXactId. If so, return TRUE. + * are older than the specified cutoff XID or MultiXactId. If so, return TRUE. * * It doesn't matter whether the tuple is alive or dead, we are checking * to see if a tuple needs to be removed or frozen to avoid wraparound. @@ -6164,7 +6164,7 @@ heap_restrpos(HeapScanDesc scan) else { /* - * If we reached end of scan, rs_inited will now be false. We must + * If we reached end of scan, rs_inited will now be false. We must * reset it to true to keep heapgettup from doing the wrong thing. */ scan->rs_inited = true; @@ -6348,7 +6348,7 @@ log_heap_clean(Relation reln, Buffer buffer, } /* - * Perform XLogInsert for a heap-freeze operation. Caller must have already + * Perform XLogInsert for a heap-freeze operation. Caller must have already * modified the buffer and marked it dirty. */ XLogRecPtr @@ -6393,7 +6393,7 @@ log_heap_freeze(Relation reln, Buffer buffer, TransactionId cutoff_xid, /* * Perform XLogInsert for a heap-visible operation. 'block' is the block * being marked all-visible, and vm_buffer is the buffer containing the - * corresponding visibility map block. Both should have already been modified + * corresponding visibility map block. Both should have already been modified * and dirtied. * * If checksums are enabled, we also add the heap_buffer to the chain to @@ -6442,7 +6442,7 @@ log_heap_visible(RelFileNode rnode, Buffer heap_buffer, Buffer vm_buffer, } /* - * Perform XLogInsert for a heap-update operation. Caller must already + * Perform XLogInsert for a heap-update operation. Caller must already * have modified the buffer(s) and marked them dirty. */ static XLogRecPtr @@ -6772,7 +6772,7 @@ heap_xlog_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid, /* * The tuple might be marked either XMAX_INVALID or XMAX_COMMITTED + - * LOCKED. Normalize to INVALID just to be sure no one gets confused. + * LOCKED. Normalize to INVALID just to be sure no one gets confused. * Also get rid of the HEAP_KEYS_UPDATED bit. */ tuple->t_infomask &= ~HEAP_XMAX_BITS; @@ -7492,7 +7492,7 @@ heap_xlog_update(XLogRecPtr lsn, XLogRecord *record, bool hot_update) /* * In normal operation, it is important to lock the two pages in * page-number order, to avoid possible deadlocks against other update - * operations going the other way. However, during WAL replay there can + * operations going the other way. However, during WAL replay there can * be no other update happening, so we don't need to worry about that. But * we *do* need to worry that we don't expose an inconsistent state to Hot * Standby queries --- so the original page can't be unlocked before we've diff --git a/src/backend/access/heap/hio.c b/src/backend/access/heap/hio.c index 8da26908daf..c6fe2cb0e37 100644 --- a/src/backend/access/heap/hio.c +++ b/src/backend/access/heap/hio.c @@ -146,7 +146,7 @@ GetVisibilityMapPins(Relation relation, Buffer buffer1, Buffer buffer2, /* * If there are two buffers involved and we pinned just one of them, * it's possible that the second one became all-visible while we were - * busy pinning the first one. If it looks like that's a possible + * busy pinning the first one. If it looks like that's a possible * scenario, we'll need to make a second pass through this loop. */ if (buffer2 == InvalidBuffer || buffer1 == buffer2 @@ -177,7 +177,7 @@ GetVisibilityMapPins(Relation relation, Buffer buffer1, Buffer buffer2, * NOTE: it is unlikely, but not quite impossible, for otherBuffer to be the * same buffer we select for insertion of the new tuple (this could only * happen if space is freed in that page after heap_update finds there's not - * enough there). In that case, the page will be pinned and locked only once. + * enough there). In that case, the page will be pinned and locked only once. * * For the vmbuffer and vmbuffer_other arguments, we avoid deadlock by * locking them only after locking the corresponding heap page, and taking @@ -198,7 +198,7 @@ GetVisibilityMapPins(Relation relation, Buffer buffer1, Buffer buffer2, * for additional constraints needed for safe usage of this behavior.) * * The caller can also provide a BulkInsertState object to optimize many - * insertions into the same relation. This keeps a pin on the current + * insertions into the same relation. This keeps a pin on the current * insertion target page (to save pin/unpin cycles) and also passes a * BULKWRITE buffer selection strategy object to the buffer manager. * Passing NULL for bistate selects the default behavior. @@ -252,7 +252,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * We first try to put the tuple on the same page we last inserted a tuple - * on, as cached in the BulkInsertState or relcache entry. If that + * on, as cached in the BulkInsertState or relcache entry. If that * doesn't work, we ask the Free Space Map to locate a suitable page. * Since the FSM's info might be out of date, we have to be prepared to * loop around and retry multiple times. (To insure this isn't an infinite @@ -284,7 +284,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * If the FSM knows nothing of the rel, try the last page before we - * give up and extend. This avoids one-tuple-per-page syndrome during + * give up and extend. This avoids one-tuple-per-page syndrome during * bootstrapping or in a recently-started system. */ if (targetBlock == InvalidBlockNumber) @@ -306,7 +306,7 @@ RelationGetBufferForTuple(Relation relation, Size len, * If the page-level all-visible flag is set, caller will need to * clear both that and the corresponding visibility map bit. However, * by the time we return, we'll have x-locked the buffer, and we don't - * want to do any I/O while in that state. So we check the bit here + * want to do any I/O while in that state. So we check the bit here * before taking the lock, and pin the page if it appears necessary. * Checking without the lock creates a risk of getting the wrong * answer, so we'll have to recheck after acquiring the lock. @@ -348,7 +348,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * We now have the target page (and the other buffer, if any) pinned - * and locked. However, since our initial PageIsAllVisible checks + * and locked. However, since our initial PageIsAllVisible checks * were performed before acquiring the lock, the results might now be * out of date, either for the selected victim buffer, or for the * other buffer passed by the caller. In that case, we'll need to @@ -391,7 +391,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * Not enough space, so we must give up our page locks and pin (if - * any) and prepare to look elsewhere. We don't care which order we + * any) and prepare to look elsewhere. We don't care which order we * unlock the two buffers in, so this can be slightly simpler than the * code above. */ @@ -433,7 +433,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * XXX This does an lseek - rather expensive - but at the moment it is the - * only way to accurately determine how many blocks are in a relation. Is + * only way to accurately determine how many blocks are in a relation. Is * it worth keeping an accurate file length in shared memory someplace, * rather than relying on the kernel to do it for us? */ @@ -453,7 +453,7 @@ RelationGetBufferForTuple(Relation relation, Size len, /* * Release the file-extension lock; it's now OK for someone else to extend - * the relation some more. Note that we cannot release this lock before + * the relation some more. Note that we cannot release this lock before * we have buffer lock on the new page, or we risk a race condition * against vacuumlazy.c --- see comments therein. */ diff --git a/src/backend/access/heap/pruneheap.c b/src/backend/access/heap/pruneheap.c index 8f0c02d9c2c..9a8db74cb95 100644 --- a/src/backend/access/heap/pruneheap.c +++ b/src/backend/access/heap/pruneheap.c @@ -100,7 +100,7 @@ heap_page_prune_opt(Relation relation, Buffer buffer, TransactionId OldestXmin) * Checking free space here is questionable since we aren't holding any * lock on the buffer; in the worst case we could get a bogus answer. It's * unlikely to be *seriously* wrong, though, since reading either pd_lower - * or pd_upper is probably atomic. Avoiding taking a lock seems more + * or pd_upper is probably atomic. Avoiding taking a lock seems more * important than sometimes getting a wrong answer in what is after all * just a heuristic estimate. */ @@ -315,8 +315,8 @@ heap_page_prune(Relation relation, Buffer buffer, TransactionId OldestXmin, * OldestXmin is the cutoff XID used to identify dead tuples. * * We don't actually change the page here, except perhaps for hint-bit updates - * caused by HeapTupleSatisfiesVacuum. We just add entries to the arrays in - * prstate showing the changes to be made. Items to be redirected are added + * caused by HeapTupleSatisfiesVacuum. We just add entries to the arrays in + * prstate showing the changes to be made. Items to be redirected are added * to the redirected[] array (two entries per redirection); items to be set to * LP_DEAD state are added to nowdead[]; and items to be set to LP_UNUSED * state are added to nowunused[]. @@ -358,7 +358,7 @@ heap_prune_chain(Relation relation, Buffer buffer, OffsetNumber rootoffnum, * We need this primarily to handle aborted HOT updates, that is, * XMIN_INVALID heap-only tuples. Those might not be linked to by * any chain, since the parent tuple might be re-updated before - * any pruning occurs. So we have to be able to reap them + * any pruning occurs. So we have to be able to reap them * separately from chain-pruning. (Note that * HeapTupleHeaderIsHotUpdated will never return true for an * XMIN_INVALID tuple, so this code will work even when there were @@ -544,7 +544,7 @@ heap_prune_chain(Relation relation, Buffer buffer, OffsetNumber rootoffnum, /* * If the root entry had been a normal tuple, we are deleting it, so - * count it in the result. But changing a redirect (even to DEAD + * count it in the result. But changing a redirect (even to DEAD * state) doesn't count. */ if (ItemIdIsNormal(rootlp)) @@ -633,7 +633,7 @@ heap_prune_record_unused(PruneState *prstate, OffsetNumber offnum) * buffer, and is inside a critical section. * * This is split out because it is also used by heap_xlog_clean() - * to replay the WAL record when needed after a crash. Note that the + * to replay the WAL record when needed after a crash. Note that the * arguments are identical to those of log_heap_clean(). */ void diff --git a/src/backend/access/heap/rewriteheap.c b/src/backend/access/heap/rewriteheap.c index 951894ce5ac..76f972e79f9 100644 --- a/src/backend/access/heap/rewriteheap.c +++ b/src/backend/access/heap/rewriteheap.c @@ -10,7 +10,7 @@ * * The caller is responsible for creating the new heap, all catalog * changes, supplying the tuples to be written to the new heap, and - * rebuilding indexes. The caller must hold AccessExclusiveLock on the + * rebuilding indexes. The caller must hold AccessExclusiveLock on the * target table, because we assume no one else is writing into it. * * To use the facility: @@ -43,7 +43,7 @@ * to substitute the correct ctid instead. * * For each ctid reference from A -> B, we might encounter either A first - * or B first. (Note that a tuple in the middle of a chain is both A and B + * or B first. (Note that a tuple in the middle of a chain is both A and B * of different pairs.) * * If we encounter A first, we'll store the tuple in the unresolved_tups @@ -58,11 +58,11 @@ * and can write A immediately with the correct ctid. * * Entries in the hash tables can be removed as soon as the later tuple - * is encountered. That helps to keep the memory usage down. At the end, + * is encountered. That helps to keep the memory usage down. At the end, * both tables are usually empty; we should have encountered both A and B * of each pair. However, it's possible for A to be RECENTLY_DEAD and B * entirely DEAD according to HeapTupleSatisfiesVacuum, because the test - * for deadness using OldestXmin is not exact. In such a case we might + * for deadness using OldestXmin is not exact. In such a case we might * encounter B first, and skip it, and find A later. Then A would be added * to unresolved_tups, and stay there until end of the rewrite. Since * this case is very unusual, we don't worry about the memory usage. @@ -78,7 +78,7 @@ * of CLUSTERing on an unchanging key column, we'll see all the versions * of a given tuple together anyway, and so the peak memory usage is only * proportional to the number of RECENTLY_DEAD versions of a single row, not - * in the whole table. Note that if we do fail halfway through a CLUSTER, + * in the whole table. Note that if we do fail halfway through a CLUSTER, * the old table is still valid, so failure is not catastrophic. * * We can't use the normal heap_insert function to insert into the new @@ -287,7 +287,7 @@ end_heap_rewrite(RewriteState state) } /* - * If the rel is WAL-logged, must fsync before commit. We use heap_sync + * If the rel is WAL-logged, must fsync before commit. We use heap_sync * to ensure that the toast table gets fsync'd too. * * It's obvious that we must do this when not WAL-logging. It's less @@ -554,7 +554,7 @@ rewrite_heap_dead_tuple(RewriteState state, HeapTuple old_tuple) } /* - * Insert a tuple to the new relation. This has to track heap_insert + * Insert a tuple to the new relation. This has to track heap_insert * and its subsidiary functions! * * t_self of the tuple is set to the new TID of the tuple. If t_ctid of the diff --git a/src/backend/access/heap/syncscan.c b/src/backend/access/heap/syncscan.c index 09384d8850b..884485ccccd 100644 --- a/src/backend/access/heap/syncscan.c +++ b/src/backend/access/heap/syncscan.c @@ -4,7 +4,7 @@ * heap scan synchronization support * * When multiple backends run a sequential scan on the same table, we try - * to keep them synchronized to reduce the overall I/O needed. The goal is + * to keep them synchronized to reduce the overall I/O needed. The goal is * to read each page into shared buffer cache only once, and let all backends * that take part in the shared scan process the page before it falls out of * the cache. @@ -26,7 +26,7 @@ * don't want such queries to slow down others. * * There can realistically only be a few large sequential scans on different - * tables in progress at any time. Therefore we just keep the scan positions + * tables in progress at any time. Therefore we just keep the scan positions * in a small LRU list which we scan every time we need to look up or update a * scan position. The whole mechanism is only applied for tables exceeding * a threshold size (but that is not the concern of this module). @@ -243,7 +243,7 @@ ss_search(RelFileNode relfilenode, BlockNumber location, bool set) * relation, or 0 if no valid location is found. * * We expect the caller has just done RelationGetNumberOfBlocks(), and - * so that number is passed in rather than computing it again. The result + * so that number is passed in rather than computing it again. The result * is guaranteed less than relnblocks (assuming that's > 0). */ BlockNumber diff --git a/src/backend/access/heap/tuptoaster.c b/src/backend/access/heap/tuptoaster.c index 219e6a635ae..55afdc8ca44 100644 --- a/src/backend/access/heap/tuptoaster.c +++ b/src/backend/access/heap/tuptoaster.c @@ -552,7 +552,7 @@ toast_insert_or_update(Relation rel, HeapTuple newtup, HeapTuple oldtup, * We took care of UPDATE above, so any external value we find * still in the tuple must be someone else's we cannot reuse. * Fetch it back (without decompression, unless we are forcing - * PLAIN storage). If necessary, we'll push it out as a new + * PLAIN storage). If necessary, we'll push it out as a new * external value below. */ if (VARATT_IS_EXTERNAL(new_value)) @@ -695,7 +695,7 @@ toast_insert_or_update(Relation rel, HeapTuple newtup, HeapTuple oldtup, /* * Second we look for attributes of attstorage 'x' or 'e' that are still - * inline. But skip this if there's no toast table to push them to. + * inline. But skip this if there's no toast table to push them to. */ while (heap_compute_data_size(tupleDesc, toast_values, toast_isnull) > maxDataLen && @@ -805,7 +805,7 @@ toast_insert_or_update(Relation rel, HeapTuple newtup, HeapTuple oldtup, } /* - * Finally we store attributes of type 'm' externally. At this point we + * Finally we store attributes of type 'm' externally. At this point we * increase the target tuple size, so that 'm' attributes aren't stored * externally unless really necessary. */ @@ -1351,7 +1351,7 @@ toast_save_datum(Relation rel, Datum value, * those versions could easily reference the same toast value. * When we copy the second or later version of such a row, * reusing the OID will mean we select an OID that's already - * in the new toast table. Check for that, and if so, just + * in the new toast table. Check for that, and if so, just * fall through without writing the data again. * * While annoying and ugly-looking, this is a good thing @@ -1417,7 +1417,7 @@ toast_save_datum(Relation rel, Datum value, heap_insert(toastrel, toasttup, mycid, options, NULL); /* - * Create the index entry. We cheat a little here by not using + * Create the index entry. We cheat a little here by not using * FormIndexDatum: this relies on the knowledge that the index columns * are the same as the initial columns of the table. * diff --git a/src/backend/access/heap/visibilitymap.c b/src/backend/access/heap/visibilitymap.c index 7f40d89b9f1..f0436859957 100644 --- a/src/backend/access/heap/visibilitymap.c +++ b/src/backend/access/heap/visibilitymap.c @@ -27,7 +27,7 @@ * the sense that we make sure that whenever a bit is set, we know the * condition is true, but if a bit is not set, it might or might not be true. * - * Clearing a visibility map bit is not separately WAL-logged. The callers + * Clearing a visibility map bit is not separately WAL-logged. The callers * must make sure that whenever a bit is cleared, the bit is cleared on WAL * replay of the updating operation as well. * @@ -36,9 +36,9 @@ * it may still be the case that every tuple on the page is visible to all * transactions; we just don't know that for certain. The difficulty is that * there are two bits which are typically set together: the PD_ALL_VISIBLE bit - * on the page itself, and the visibility map bit. If a crash occurs after the + * on the page itself, and the visibility map bit. If a crash occurs after the * visibility map page makes it to disk and before the updated heap page makes - * it to disk, redo must set the bit on the heap page. Otherwise, the next + * it to disk, redo must set the bit on the heap page. Otherwise, the next * insert, update, or delete on the heap page will fail to realize that the * visibility map bit must be cleared, possibly causing index-only scans to * return wrong answers. @@ -59,10 +59,10 @@ * the buffer lock over any I/O that may be required to read in the visibility * map page. To avoid this, we examine the heap page before locking it; * if the page-level PD_ALL_VISIBLE bit is set, we pin the visibility map - * bit. Then, we lock the buffer. But this creates a race condition: there + * bit. Then, we lock the buffer. But this creates a race condition: there * is a possibility that in the time it takes to lock the buffer, the * PD_ALL_VISIBLE bit gets set. If that happens, we have to unlock the - * buffer, pin the visibility map page, and relock the buffer. This shouldn't + * buffer, pin the visibility map page, and relock the buffer. This shouldn't * happen often, because only VACUUM currently sets visibility map bits, * and the race will only occur if VACUUM processes a given page at almost * exactly the same time that someone tries to further modify it. @@ -227,9 +227,9 @@ visibilitymap_pin_ok(BlockNumber heapBlk, Buffer buf) * visibilitymap_set - set a bit on a previously pinned page * * recptr is the LSN of the XLOG record we're replaying, if we're in recovery, - * or InvalidXLogRecPtr in normal running. The page LSN is advanced to the + * or InvalidXLogRecPtr in normal running. The page LSN is advanced to the * one provided; in normal running, we generate a new XLOG record and set the - * page LSN to that value. cutoff_xid is the largest xmin on the page being + * page LSN to that value. cutoff_xid is the largest xmin on the page being * marked all-visible; it is needed for Hot Standby, and can be * InvalidTransactionId if the page contains no tuples. * @@ -320,10 +320,10 @@ visibilitymap_set(Relation rel, BlockNumber heapBlk, Buffer heapBuf, * releasing *buf after it's done testing and setting bits. * * NOTE: This function is typically called without a lock on the heap page, - * so somebody else could change the bit just after we look at it. In fact, + * so somebody else could change the bit just after we look at it. In fact, * since we don't lock the visibility map page either, it's even possible that * someone else could have changed the bit just before we look at it, but yet - * we might see the old value. It is the caller's responsibility to deal with + * we might see the old value. It is the caller's responsibility to deal with * all concurrency issues! */ bool @@ -526,7 +526,7 @@ vm_readbuf(Relation rel, BlockNumber blkno, bool extend) /* * We might not have opened the relation at the smgr level yet, or we - * might have been forced to close it by a sinval message. The code below + * might have been forced to close it by a sinval message. The code below * won't necessarily notice relation extension immediately when extend = * false, so we rely on sinval messages to ensure that our ideas about the * size of the map aren't too far out of date. |