RE: Logical replication timeout problem
От | wangw.fnst@fujitsu.com |
---|---|
Тема | RE: Logical replication timeout problem |
Дата | |
Msg-id | OS3PR01MB6275C64F264662E84D2FB7AE9E1D9@OS3PR01MB6275.jpnprd01.prod.outlook.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("kuroda.hayato@fujitsu.com" <kuroda.hayato@fujitsu.com>) |
Ответы |
Re: Logical replication timeout problem
RE: Logical replication timeout problem |
Список | pgsql-hackers |
On Mon, Mar 28, 2022 at 9:56 AM Kuroda, Hayato/黒田 隼人 <kuroda.hayato@fujitsu.com> wrote: > Dear Wang-san, Thanks for your comments. > Thank you for updating! > ...but it also cannot be applied to current HEAD > because of the commit 923def9a533. > > Your patch seems to conflict the adding an argument of > logicalrep_write_insert(). > It allows specifying columns to publish by skipping some columns in > logicalrep_write_tuple() > which is called from logicalrep_write_insert() and logicalrep_write_update(). Thank for your kindly reminder. Rebase the patch. > Do we have to consider something special case for that? > I thought timeout may occur if users have huge table and publish few columns, > but it is corner case. I think maybe we do not need to deal with this use case. The maximum number of table columns allowed by PG is 1600 (macro MaxHeapAttributeNumber), and after loop through all columns in the function logicalrep_write_tuple, the function OutputPluginWrite will be invoked immediately to actually send the data to the subscriber. This refreshes the last time the subscriber received a message. So I think this loop will not cause timeout issues. Regards, Wang wei
Вложения
В списке pgsql-hackers по дате отправления: