On Thu, Jan 22, 2022 at 7:12 PM Amit Kapila <amit.kapil...@gmail.com> wrote: > Now, one idea to solve this problem could be that whenever we skip > sending any change we do try to update the plugin progress via > OutputPluginUpdateProgress(for walsender, it will invoke > WalSndUpdateProgress), and there it tries to process replies and send > keep_alive if necessary as we do when we send some data via > OutputPluginWrite(for walsender, it will invoke WalSndWriteData). I > don't know whether it is a good idea to invoke such a mechanism for > every change we skip to send or we should do it after we skip sending > some threshold of continuous changes. I think later would be > preferred. Also, we might want to introduce a new parameter > send_keep_alive to this API so that there is flexibility to invoke > this mechanism as we don't need to invoke it while we are actually > sending data and before that, we just update the progress via this > API.
I tried out the patch according to your advice. I found if I invoke ProcessRepliesIfAny and WalSndKeepaliveIfNecessary in function OutputPluginUpdateProgress, the running time of the newly added function OutputPluginUpdateProgress invoked in pgoutput_change brings notable overhead: --11.34%--pgoutput_change | |--8.94%--OutputPluginUpdateProgress | | | --8.70%--WalSndUpdateProgress | | | |--7.44%--ProcessRepliesIfAny So I tried another way of sending keepalive message to the standby machine based on the timeout without asking for a reply(see attachment), the running time of the newly added function OutputPluginUpdateProgress invoked in pgoutput_change also brings slight overhead: --3.63%--pgoutput_change | |--1.40%--get_rel_sync_entry | | | --1.14%--hash_search | --1.08%--OutputPluginUpdateProgress | --0.85%--WalSndUpdateProgress Based on above, I think the second idea that sending some threshold of continuous changes might be better, I will do some research about this approach. Regards, Wang wei
0001-Fix-the-timeout-of-subscriber-in-long-transactions.patch
Description: 0001-Fix-the-timeout-of-subscriber-in-long-transactions.patch