@@ -5311,7 +5311,7 @@ heap_lock_updated_tuple_rec(Relation rel, ItemPointer tid, TransactionId xid,
5311
5311
*
5312
5312
* The initial tuple is assumed to be already locked.
5313
5313
*
5314
- * This function doesn't check visibility, it justinconditionally marks the
5314
+ * This function doesn't check visibility, it justunconditionally marks the
5315
5315
* tuple(s) as locked. If any tuple in the updated chain is being deleted
5316
5316
* concurrently (or updated with the key being modified), sleep until the
5317
5317
* transaction doing it is finished.
@@ -5798,7 +5798,7 @@ heap_prepare_freeze_tuple(HeapTupleHeader tuple, TransactionId cutoff_xid,
5798
5798
/*
5799
5799
* NB -- some of these transformations are only valid because we
5800
5800
* know the return Xid is a tuple updater (i.e. not merely a
5801
- * locker.) Also note that the only reason we don'texplicitely
5801
+ * locker.) Also note that the only reason we don'texplicitly
5802
5802
* worry about HEAP_KEYS_UPDATED is because it lives in
5803
5803
* t_infomask2 rather than t_infomask.
5804
5804
*/