32
32
*
33
33
* In order to cope with large transactions - which can be several times as
34
34
* big as the available memory - this module supports spooling the contents
35
- * of a large transactions to disk. When the transaction is replayed the
35
+ * of large transactions to disk. When the transaction is replayed the
36
36
* contents of individual (sub-)transactions will be read from disk in
37
37
* chunks.
38
38
*
@@ -3078,10 +3078,10 @@ ReorderBufferImmediateInvalidation(ReorderBuffer *rb, uint32 ninvalidations,
3078
3078
* least once for every xid in XLogRecord->xl_xid (other places in records
3079
3079
* may, but do not have to be passed through here).
3080
3080
*
3081
- * Reorderbuffer keeps some datastructures about transactions in LSN order,
3081
+ * Reorderbuffer keeps some data structures about transactions in LSN order,
3082
3082
* for efficiency. To do that it has to know about when transactions are seen
3083
3083
* first in the WAL. As many types of records are not actually interesting for
3084
- * logical decoding, they do not necessarily pass though here.
3084
+ * logical decoding, they do not necessarily pass through here.
3085
3085
*/
3086
3086
void
3087
3087
ReorderBufferProcessXid (ReorderBuffer * rb , TransactionId xid , XLogRecPtr lsn )
@@ -3513,11 +3513,11 @@ ReorderBufferLargestTXN(ReorderBuffer *rb)
3513
3513
* snapshot because we don't decode such transactions. Also, we do not select
3514
3514
* the transaction which doesn't have any streamable change.
3515
3515
*
3516
- * Note that, we skip transactions that contains incomplete changes. There
3516
+ * Note that, we skip transactions that contain incomplete changes. There
3517
3517
* is a scope of optimization here such that we can select the largest
3518
3518
* transaction which has incomplete changes. But that will make the code and
3519
3519
* design quite complex and that might not be worth the benefit. If we plan to
3520
- * stream the transactions that contains incomplete changes then we need to
3520
+ * stream the transactions that contain incomplete changes then we need to
3521
3521
* find a way to partially stream/truncate the transaction changes in-memory
3522
3522
* and build a mechanism to partially truncate the spilled files.
3523
3523
* Additionally, whenever we partially stream the transaction we need to
@@ -4701,8 +4701,8 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn,
4701
4701
}
4702
4702
4703
4703
/*
4704
- * Rejigger change->newtuple to point to in-memory toast tuples instead to
4705
- * on-disk toast tuples that may not longer exist (think DROP TABLE or VACUUM).
4704
+ * Rejigger change->newtuple to point to in-memory toast tuples instead of
4705
+ * on-disk toast tuples that may no longer exist (think DROP TABLE or VACUUM).
4706
4706
*
4707
4707
* We cannot replace unchanged toast tuples though, so those will still point
4708
4708
* to on-disk toast data.
@@ -4713,7 +4713,7 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn,
4713
4713
* at unexpected times.
4714
4714
*
4715
4715
* We simply subtract size of the change before rejiggering the tuple, and
4716
- * then adding the new size. This makes it look like the change was removed
4716
+ * then add the new size. This makes it look like the change was removed
4717
4717
* and then added back, except it only tweaks the accounting info.
4718
4718
*
4719
4719
* In particular it can't trigger serialization, which would be pointless
0 commit comments