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

From: Sergey Belyashov <sergey(dot)belyashov(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: PostgreSQL mailing lists <pgsql-bugs(at)lists(dot)postgresql(dot)org>
Subject: Re: BUG #17438: Logical replication hangs on master after huge DB load
Date: 2022-03-16 12:09:30
Message-ID: CAOe0RDwDiHrV43KunAD27wqvXDr35jCw21bUONxRuorSUBWEAA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

ср, 16 мар. 2022 г. в 14:45, Amit Kapila <amit(dot)kapila16(at)gmail(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2022-03-16 17:27:56 Re: BUG #17439: DROP FUNCTION functionName(); drops associated generated column without using CASCADE
Previous Message Amit Kapila 2022-03-16 11:45:27 Re: BUG #17438: Logical replication hangs on master after huge DB load