Re: BUG #17438: Logical replication hangs on master after huge DB load

Поиск
Список
Период
Сортировка
От Sergey Belyashov
Тема Re: BUG #17438: Logical replication hangs on master after huge DB load
Дата
Msg-id CAOe0RDwDiHrV43KunAD27wqvXDr35jCw21bUONxRuorSUBWEAA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: BUG #17438: Logical replication hangs on master after huge DB load  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: BUG #17438: Logical replication hangs on master after huge DB load  (Amit Kapila <amit.kapila16@gmail.com>)
Список pgsql-bugs
ср, 16 мар. 2022 г. в 14:45, Amit Kapila <amit.kapila16@gmail.com>:
>
> Is it possible to get some reproducible script/test for this problem?

I have not tried to do it. But it is always reproducible for me: I try
to do it on different servers. My maintenance work takes more than 4
hours. There is no difference, do I "insert into x select * from C" or
"alter table C alter column X type text" (I did this command initially
for each detached partition, but have issues with subscriptions, so I
try to change column type by copying table partitions to new table).

>
> Just by seeing these LOGs, it seems subscriber side workers are
> exiting due to some error and publisher-side (WALSender) still
> continues due to which I think we are seeing ""A_sub" is active for
> PID 1766849". Do you see any different type of error in
> subscriber-side logs?
>

No errors other than those provided in the previous email.

Sergey Belyashov



В списке pgsql-bugs по дате отправления:

Предыдущее
От: Amit Kapila
Дата:
Сообщение: Re: BUG #17438: Logical replication hangs on master after huge DB load
Следующее
От: Tom Lane
Дата:
Сообщение: Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE