diff options
author | Amit Kapila <akapila@postgresql.org> | 2020-07-18 09:47:38 +0530 |
---|---|---|
committer | Amit Kapila <akapila@postgresql.org> | 2020-07-18 09:47:38 +0530 |
commit | df7c5cb16e8fcf960e3302355fa6547fba428f5e (patch) | |
tree | 3afcdbdd07530dbf033453498dcb19bfeae21fe4 /src | |
parent | b74d449a02b3c972051b1847f3915128da8775dc (diff) | |
download | postgresql-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')
-rw-r--r-- | src/backend/replication/logical/reorderbuffer.c | 10 |
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. * * ------------------------------------------------------------------------- */ |