mirrors/postgres
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Fix comments in reorderbuffer.c.

Browse Source 
Author: Dave Cramer
Reviewed-by: David G. Johnston
Discussion: https://postgr.es/m/CADK3HHL8do4Fp1bsymgNasx375njV3AR7zY3UgYwzbL_Dx-n2Q@mail.gmail.com
This commit is contained in:
Amit Kapila 2020-07-18 09:47:38 +05:30
parent b74d449a02
commit df7c5cb16e
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

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

@ -47,7 +47,7 @@
* ReorderBuffer uses two special memory context types - SlabContext for * ReorderBuffer uses two special memory context types - SlabContext for
* allocations of fixed-length structures (changes and transactions), and * allocations of fixed-length structures (changes and transactions), and
* GenerationContext for the variable-length transaction data (allocated * 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 * 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 * 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 * Only decoded changes are evicted from memory (spilled to disk), not the
* transaction records. The number of toplevel transactions is limited, * transaction records. The number of toplevel transactions is limited,
* but a transaction with many subtransactions may still consume significant * 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. * are not included in the memory limit.
* *
* The current eviction algorithm is very simple - the transaction is * 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 * 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 * 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 * 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 * 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 * deserializing and applying very few changes). We probably should give
* a bit more memory to the oldest subtransactions, because it's likely * 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.
* *
* ------------------------------------------------------------------------- * -------------------------------------------------------------------------
*/ */