Re: Logical replication timeout problem

On Thu, Apr 14, 2022 at 5:50 PM Masahiko Sawada <sawada.mshk@gmail.com> wrote:
>
> On Wed, Apr 13, 2022 at 7:45 PM Amit Kapila <amit.kapila16@gmail.com> wrote:
> >
> > On Mon, Apr 11, 2022 at 12:09 PM wangw.fnst@fujitsu.com
> > <wangw.fnst@fujitsu.com> wrote:
> > >
> > > So I skip tracking lag during a transaction just like the current HEAD.
> > > Attach the new patch.
> > >
> >
> > Thanks, please find the updated patch where I have slightly modified
> > the comments.
> >
> > Sawada-San, Euler, do you have any opinion on this approach? I
> > personally still prefer the approach implemented in v10 [1] especially
> > due to the latest finding by Wang-San that we can't update the
> > lag-tracker apart from when it is invoked at the transaction end.
> > However, I am fine if we like this approach more.
>
> Thank you for updating the patch.
>
> The current patch looks much better than v10 which requires to call to
> update_progress() every path.
>
> Regarding v15 patch, I'm concerned a bit that the new function name,
> update_progress(), is too generic. How about
> update_replation_progress() or something more specific name?
>

Do you intend to say update_replication_progress()? The word
'replation' doesn't make sense to me. I am fine with this suggestion.

>
> ---
> +        if (end_xact)
> +        {
> +                /* Update progress tracking at xact end. */
> +                OutputPluginUpdateProgress(ctx, skipped_xact, end_xact);
> +                changes_count = 0;
> +                return;
> +        }
> +
> +        /*
> +         * After continuously processing CHANGES_THRESHOLD changes,
> we try to send
> +         * a keepalive message if required.
> +         *
> +         * We don't want to try sending a keepalive message after
> processing each
> +         * change as that can have overhead. Testing reveals that there is no
> +         * noticeable overhead in doing it after continuously
> processing 100 or so
> +         * changes.
> +         */
> +#define CHANGES_THRESHOLD 100
> +        if (++changes_count >= CHANGES_THRESHOLD)
> +        {
> +                OutputPluginUpdateProgress(ctx, skipped_xact, end_xact);
> +                changes_count = 0;
> +        }
>
> Can we merge two if branches since we do the same things? Or did you
> separate them for better readability?
>

I think it is fine to merge the two checks.

-- 
With Regards,
Amit Kapila.