On Thu, Jan 20, 2022 at 2:35 PM wangw.f...@fujitsu.com
<wangw.f...@fujitsu.com> wrote:
>
> On Wed, Jan 19, 2022 at 9:53 PM Fabrice Chapuis fabrice636...@gmail.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.
