RE: Logical replication timeout problem
От | wangw.fnst@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | OS3PR01MB627501E0770E20F517D020379E2D9@OS3PR01MB6275.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>) |
Ответы |
RE: Logical replication timeout problem
Re: Logical replication timeout problem Re: Logical replication timeout problem |
Список | pgsql-hackers |
On Wed, Jan 26, 2022 at 11:37 AM I wrote: > On Sat, Jan 22, 2022 at 7:12 PM Amit Kapila <amit.kapila16@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). Regards, Wang wei
Вложения
В списке pgsql-hackers по дате отправления: