From 760f6ecff89194571524d610e5ece2dbeec6d373 Mon Sep 17 00:00:00 2001 From: Justin Pryzby Date: Sat, 19 Dec 2020 03:27:23 -0600 Subject: [PATCH 13/17] Doc review for logical decoding stream methods: 45fdc9738 See also: 9e0f87a4955ede0769d2f9a93171145b6ddab901 8e90ec5580d5345fef31005d7cc2215ba2125070 --- doc/src/sgml/logicaldecoding.sgml | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/src/sgml/logicaldecoding.sgml b/doc/src/sgml/logicaldecoding.sgml index 813a037fac..ca78a81e9c 100644 --- a/doc/src/sgml/logicaldecoding.sgml +++ b/doc/src/sgml/logicaldecoding.sgml @@ -953,11 +953,11 @@ stream_commit_cb(...); <-- commit of the streamed transaction Similar to spill-to-disk behavior, streaming is triggered when the total amount of changes decoded from the WAL (for all in-progress transactions) - exceeds limit defined by logical_decoding_work_mem setting. - At that point the largest toplevel transaction (measured by amount of memory + exceeds the limit defined by logical_decoding_work_mem setting. + At that point, the largest toplevel transaction (measured by the amount of memory currently used for decoded changes) is selected and streamed. However, in - some cases we still have to spill to the disk even if streaming is enabled - because if we cross the memory limit but we still have not decoded the + some cases we still have to spill to disk even if streaming is enabled + because we exceed the memory threshold but still have not decoded the complete tuple e.g., only decoded toast table insert but not the main table insert. -- 2.17.0