RE: Logical replication timeout problem
От | wangw.fnst@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | OS3PR01MB6275EB73DD9FD9E3F634E2699ED39@OS3PR01MB6275.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("shiy.fnst@fujitsu.com" <shiy.fnst@fujitsu.com>) |
Ответы |
Re: Logical replication timeout problem
|
Список | pgsql-hackers |
On Mon, Jan 30, 2023 11:37 AM Shi, Yu/侍 雨 <shiy.fnst@cn.fujitsu.com> wrote: > On Sun, Jan 29, 2023 3:41 PM wangw.fnst@fujitsu.com > <wangw.fnst@fujitsu.com> wrote: > > > > I tested a mix transaction of transactional and non-transactional messages on > > the current HEAD and reproduced the timeout problem. I think this result is > OK. > > Because when decoding a transaction, non-transactional changes are > processed > > directly and the function WalSndKeepaliveIfNecessary is called, while > > transactional changes are cached and processed after decoding. After > decoding, > > only transactional changes will be processed (in the function > > ReorderBufferProcessTXN), so the timeout problem will still be reproduced. > > > > After applying the v8 patch, the test mentioned above didn't reproduce the > > timeout problem (Attach this test script 'test_with_nontransactional.sh'). > > > > Attach the new patch. > > > > Thanks for updating the patch. Here is a comment. Thanks for your comment. > In update_progress_txn_cb_wrapper(), it looks like we need to reset > changes_count to 0 after calling OutputPluginUpdateProgress(), otherwise > OutputPluginUpdateProgress() will always be called after 100 changes. Yes, I think you are right. Fixed this problem. Attach the new patch. Regards, Wang Wei
Вложения
В списке pgsql-hackers по дате отправления: