Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 9c40db3

Browse files
author
Amit Kapila
committed
Fix typos in reorderbuffer.c.
Author: Kyotaro Horiguchi Discussion: https://postgr.es/m/20240314.132817.1496502692848380820.horikyota.ntt@gmail.com
1 parent 2d819a0 commit 9c40db3

File tree

1 file changed

+8
-8
lines changed

1 file changed

+8
-8
lines changed

src/backend/replication/logical/reorderbuffer.c

+8-8
Original file line numberDiff line numberDiff line change
@@ -32,7 +32,7 @@
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-
* of a 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 some datastructures about transactions in LSN order,
3081+
* Reorderbuffer keeps some data 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 pass though here.
3084+
* logical decoding, they do not necessarily pass through here.
30853085
*/
30863086
void
30873087
ReorderBufferProcessXid(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 that contains incomplete changes. There
3516+
* Note that, we skip transactions that contain 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 that contains incomplete changes then we need to
3520+
* stream the transactions that contain 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 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).
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-
* 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
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

0 commit comments

Comments
 (0)