RE: Logical replication timeout problem
От | shiy.fnst@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | OSZPR01MB631040D5A14BE71AB67317B9FDD39@OSZPR01MB6310.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>) |
Ответы |
RE: Logical replication timeout problem
|
Список | pgsql-hackers |
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. 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. Regards, Shi yu
В списке pgsql-hackers по дате отправления: