aboutsummaryrefslogtreecommitdiff
path: root/src/backend/replication/logical/reorderbuffer.c
diff options
context:
space:
mode:
authorAmit Kapila <akapila@postgresql.org>2020-07-18 09:47:38 +0530
committerAmit Kapila <akapila@postgresql.org>2020-07-18 09:47:38 +0530
commitdf7c5cb16e8fcf960e3302355fa6547fba428f5e (patch)
tree3afcdbdd07530dbf033453498dcb19bfeae21fe4 /src/backend/replication/logical/reorderbuffer.c
parentb74d449a02b3c972051b1847f3915128da8775dc (diff)
downloadpostgresql-df7c5cb16e8fcf960e3302355fa6547fba428f5e.tar.gz
postgresql-df7c5cb16e8fcf960e3302355fa6547fba428f5e.zip
Fix comments in reorderbuffer.c.
Author: Dave Cramer Reviewed-by: David G. Johnston Discussion: https://postgr.es/m/CADK3HHL8do4Fp1bsymgNasx375njV3AR7zY3UgYwzbL_Dx-n2Q@mail.gmail.com
Diffstat (limited to 'src/backend/replication/logical/reorderbuffer.c')
-rw-r--r--src/backend/replication/logical/reorderbuffer.c10
1 files changed, 5 insertions, 5 deletions
diff --git a/src/backend/replication/logical/reorderbuffer.c b/src/backend/replication/logical/reorderbuffer.c
index 52519326690..4adbe21dfc9 100644
--- a/src/backend/replication/logical/reorderbuffer.c
+++ b/src/backend/replication/logical/reorderbuffer.c
@@ -47,7 +47,7 @@
* ReorderBuffer uses two special memory context types - SlabContext for
* allocations of fixed-length structures (changes and transactions), and
* GenerationContext for the variable-length transaction data (allocated
- * and freed in groups with similar lifespan).
+ * and freed in groups with similar lifespans).
*
* To limit the amount of memory used by decoded changes, we track memory
* used at the reorder buffer level (i.e. total amount of memory), and for
@@ -58,7 +58,7 @@
* Only decoded changes are evicted from memory (spilled to disk), not the
* transaction records. The number of toplevel transactions is limited,
* but a transaction with many subtransactions may still consume significant
- * amounts of memory. The transaction records are fairly small, though, and
+ * amounts of memory. The transaction records are fairly small though and
* are not included in the memory limit.
*
* The current eviction algorithm is very simple - the transaction is
@@ -69,13 +69,13 @@
*
* We still rely on max_changes_in_memory when loading serialized changes
* back into memory. At that point we can't use the memory limit directly
- * as we load the subxacts independently. One option do deal with this
+ * as we load the subxacts independently. One option to deal with this
* would be to count the subxacts, and allow each to allocate 1/N of the
* memory limit. That however does not seem very appealing, because with
- * many subtransactions it may easily cause trashing (short cycles of
+ * many subtransactions it may easily cause thrashing (short cycles of
* deserializing and applying very few changes). We probably should give
* a bit more memory to the oldest subtransactions, because it's likely
- * the source for the next sequence of changes.
+ * they are the source for the next sequence of changes.
*
* -------------------------------------------------------------------------
*/