On Wednesday, January 25, 2023 7:26 PM Amit Kapila <amit.kapila16@gmail.com>
>
> On Tue, Jan 24, 2023 at 8:15 AM wangw.fnst@fujitsu.com
> <wangw.fnst@fujitsu.com> wrote:
> >
> > Attach the new patch.
> >
>
> I think the patch missed to handle the case of non-transactional messages which
> was previously getting handled. I have tried to address that in the attached. Is
> there a reason that shouldn't be handled?
Thanks for updating the patch!
I thought about the non-transactional message. I think it seems fine if we
don’t handle it for timeout because such message is decoded via:
WalSndLoop
-XLogSendLogical
--LogicalDecodingProcessRecord
---logicalmsg_decode
----ReorderBufferQueueMessage
-----rb->message() -- //maybe send the message or do nothing here.
After invoking rb->message(), we will directly return to the main
loop(WalSndLoop) where we will get a chance to call
WalSndKeepaliveIfNecessary() to avoid the timeout.
This is a bit different from transactional changes, because for transactional changes, we
will buffer them and then send every buffered change one by one(via
ReorderBufferProcessTXN) without going back to the WalSndLoop, so we don't get
a chance to send keepalive message if necessary, which is more likely to cause the
timeout problem.
I will also test the non-transactional message for timeout in case I missed something.
Best Regards,
Hou zj
