Re: BUG #17438: Logical replication hangs on master after huge DB load - Mailing list pgsql-bugs

From Sergey Belyashov
Subject Re: BUG #17438: Logical replication hangs on master after huge DB load
Date
Msg-id CAOe0RDwDiHrV43KunAD27wqvXDr35jCw21bUONxRuorSUBWEAA@mail.gmail.com
Whole thread Raw
In response to Re: BUG #17438: Logical replication hangs on master after huge DB load  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: BUG #17438: Logical replication hangs on master after huge DB load  (Amit Kapila <amit.kapila16@gmail.com>)
List 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 by date:

Previous
From: Amit Kapila
Date:
Subject: Re: BUG #17438: Logical replication hangs on master after huge DB load
Next
From: Tom Lane
Date:
Subject: Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE