Re: Logical replication timeout problem

On Thu, Jan 20, 2022 at 2:35 PM wangw(dot)fnst(at)fujitsu(dot)com
<wangw(dot)fnst(at)fujitsu(dot)com> wrote:
>
> On Wed, Jan 19, 2022 at 9:53 PM Fabrice Chapuis fabrice636861(at)gmail(dot)com wrote:
>
> > Hello Amit,
>
> > If it takes little work for you, can you please send me a piece of code
>
> > with the change needed to do the test
>
>
>
> I wrote a patch(Send-keepalive.patch, please refer to attachment) according to
>
> Amit's suggestions. But after I did some simple test about this patch by the
>
> test script "test.sh"(please refer to attachment), I found the timeout problem
>
> has not been fixed by this patch.
>
>
>
> So I add some logs(please refer to Add-some-logs-to-debug.patch) to confirm newly
>
> added WalSndKeepaliveIfNecessary() send keepalive message or not.
>
>
>
> After applying the Send-keepalive.patch and Add-some-logs-to-debug.patch, I
>
> found that the added message "send keep alive message" was not printed in
>
> publisher-side log.
>

It might be not reaching the actual send_keep_alive logic in
WalSndKeepaliveIfNecessary because of below code:
{
...
/*
* Don't send keepalive messages if timeouts are globally disabled or
* we're doing something not partaking in timeouts.
*/
if (wal_sender_timeout <= 0 || last_reply_timestamp <= 0)
return;
..
}

I think you can add elog before the above return and before updating
progress in the below code:
case REORDER_BUFFER_CHANGE_INSERT:
if (!relentry->pubactions.pubinsert)
+ {
+ OutputPluginUpdateProgress(ctx);
return;

This will help us to rule out one possibility.

--
With Regards,
Amit Kapila.