rdelaage
/
postgresql
mirror of https://git.postgresql.org/git/postgresql.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Fix typos in reorderbuffer.c. 

Author: Kyotaro Horiguchi
Discussion: https://postgr.es/m/20240314.132817.1496502692848380820.horikyota.ntt@gmail.com
This commit is contained in:
Amit Kapila 2024-03-14 12:12:55 +05:30
parent 2d819a08a1
commit 9c40db3b02
1 changed files with 8 additions and 8 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
src/backend/replication/logical/reorderbuffer.c
View File

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