On Tue, Feb 8, 2022 at 1:59 PM wangw.f...@fujitsu.com <wangw.f...@fujitsu.com> wrote: > > On Wed, Jan 26, 2022 at 11:37 AM I wrote: > > On Sat, 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. > > ...... > > 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. > Based on the second idea, I wrote a new patch(see attachment).
Hi Wang, Some comments: I see you only track skipped Inserts/Updates and Deletes. What about DDL operations that are skipped, what about truncate. What about changes made to unpublished tables? I wonder if you could create a test script that only did DDL operations and truncates, would this timeout happen? regards, Ajin Cherian Fujitsu Australia
