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

  1. Add 'logical_decoding_mode' GUC.

  2. Clean up some inconsistencies with GUC declarations