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

Amit Kapila <amit.kapila16@gmail.com>

From: Amit Kapila <amit.kapila16@gmail.com>
To: Sergey Belyashov <sergey.belyashov@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-03-29T12:03:08Z
Lists: pgsql-bugs
On Wed, Mar 16, 2022 at 5:39 PM Sergey Belyashov
<sergey.belyashov@gmail.com> wrote:
>
> ср, 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).
>

Is my understanding correct that this problem occurs only when you are
doing large operations of tables that are not published (like C or D)
in your case?

> >
> > 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.
>

It is difficult for me to deduce anything from the errors given. I
think we need some more information from the logs to find the reason.
One idea could be that we run the subscriber with log_min_messages as
debug1 as that might give some more information in logs.


-- 
With Regards,
Amit Kapila.