Re: Force streaming every change in logical decoding
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: "Hayato Kuroda (Fujitsu)" <kuroda.hayato@fujitsu.com>
Cc: "shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>,
Kyotaro Horiguchi <horikyota.ntt@gmail.com>, "sawada.mshk@gmail.com" <sawada.mshk@gmail.com>,
"smithpb2250@gmail.com" <smithpb2250@gmail.com>, "dilipbalaut@gmail.com" <dilipbalaut@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>
Date: 2022-12-23T05:32:27Z
Lists: pgsql-hackers
On Fri, Dec 23, 2022 at 10:48 AM Hayato Kuroda (Fujitsu) <kuroda.hayato@fujitsu.com> wrote: > > ``` > + * If logical_decoding_mode is immediate, loop until there's no change. > + * Otherwise, loop until we reach under the memory limit. One might think > + * that just by evicting the largest (sub)transaction we will come under > + * the memory limit based on assumption that the selected transaction is > + * at least as large as the most recent change (which caused us to go over > + * the memory limit). However, that is not true because a user can reduce > + * the logical_decoding_work_mem to a smaller value before the most recent > * change. > */ > ``` > > Do we need to pick the largest (sub)transaciton even if we are in the immediate mode? > It seems that the liner search is done in ReorderBufferLargestStreamableTopTXN() > to find the largest transaction, but in this case we can choose the arbitrary one. > In immediate mode, we will stream/spill each change, so ideally, we don't need to perform any search. Otherwise, also, I think changing those functions will complicate the code without serving any purpose. -- With Regards, Amit Kapila.
Commits
-
Add 'logical_decoding_mode' GUC.
- 5de94a041ed7 16.0 landed
-
Clean up some inconsistencies with GUC declarations
- d9d873bac670 16.0 cited