3232 *
3333 * In order to cope with large transactions - which can be several times as
3434 * big as the available memory - this module supports spooling the contents
35- * ofa large transactions to disk. When the transaction is replayed the
35+ * of large transactions to disk. When the transaction is replayed the
3636 * contents of individual (sub-)transactions will be read from disk in
3737 * chunks.
3838 *
@@ -3078,10 +3078,10 @@ ReorderBufferImmediateInvalidation(ReorderBuffer *rb, uint32 ninvalidations,
30783078 * least once for every xid in XLogRecord->xl_xid (other places in records
30793079 * may, but do not have to be passed through here).
30803080 *
3081- * Reorderbuffer keeps somedatastructures about transactions in LSN order,
3081+ * Reorderbuffer keeps somedata structures about transactions in LSN order,
30823082 * for efficiency. To do that it has to know about when transactions are seen
30833083 * first in the WAL. As many types of records are not actually interesting for
3084- * logical decoding, they do not necessarily passthough here.
3084+ * logical decoding, they do not necessarily passthrough here.
30853085 */
30863086void
30873087ReorderBufferProcessXid (ReorderBuffer * rb ,TransactionId xid ,XLogRecPtr lsn )
@@ -3513,11 +3513,11 @@ ReorderBufferLargestTXN(ReorderBuffer *rb)
35133513 * snapshot because we don't decode such transactions. Also, we do not select
35143514 * the transaction which doesn't have any streamable change.
35153515 *
3516- * Note that, we skip transactions thatcontains incomplete changes. There
3516+ * Note that, we skip transactions thatcontain incomplete changes. There
35173517 * is a scope of optimization here such that we can select the largest
35183518 * transaction which has incomplete changes. But that will make the code and
35193519 * design quite complex and that might not be worth the benefit. If we plan to
3520- * stream the transactions thatcontains incomplete changes then we need to
3520+ * stream the transactions thatcontain incomplete changes then we need to
35213521 * find a way to partially stream/truncate the transaction changes in-memory
35223522 * and build a mechanism to partially truncate the spilled files.
35233523 * Additionally, whenever we partially stream the transaction we need to
@@ -4701,8 +4701,8 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn,
47014701}
47024702
47034703/*
4704- * Rejigger change->newtuple to point to in-memory toast tuples insteadto
4705- * on-disk toast tuples that maynot longer exist (think DROP TABLE or VACUUM).
4704+ * Rejigger change->newtuple to point to in-memory toast tuples insteadof
4705+ * on-disk toast tuples that mayno longer exist (think DROP TABLE or VACUUM).
47064706 *
47074707 * We cannot replace unchanged toast tuples though, so those will still point
47084708 * to on-disk toast data.
@@ -4713,7 +4713,7 @@ ReorderBufferToastAppendChunk(ReorderBuffer *rb, ReorderBufferTXN *txn,
47134713 * at unexpected times.
47144714 *
47154715 * We simply subtract size of the change before rejiggering the tuple, and
4716- * thenadding the new size. This makes it look like the change was removed
4716+ * thenadd the new size. This makes it look like the change was removed
47174717 * and then added back, except it only tweaks the accounting info.
47184718 *
47194719 * In particular it can't trigger serialization, which would be pointless
