Re: Logical replication timeout problem
От | Amit Kapila |
---|---|
Тема | Re: Logical replication timeout problem |
Дата | |
Msg-id | CAA4eK1+TiukvteMXpO4dZtraF-SJHkS9UtTpa5i4P3ir_urOJw@mail.gmail.com обсуждение исходный текст |
Ответ на | RE: Logical replication timeout problem ("wangw.fnst@fujitsu.com" <wangw.fnst@fujitsu.com>) |
Ответы |
RE: Logical replication timeout problem
|
Список | pgsql-hackers |
On Mon, Mar 28, 2022 at 11:41 AM wangw.fnst@fujitsu.com <wangw.fnst@fujitsu.com> wrote: > > On Mon, Mar 28, 2022 at 9:56 AM Kuroda, Hayato/黒田 隼人 <kuroda.hayato@fujitsu.com> wrote: > > > 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. > Right, I also don't think it can be a source of timeout. -- With Regards, Amit Kapila.
В списке pgsql-hackers по дате отправления: