From: | 巨鲸 <13207961(at)qq(dot)com> |
---|---|
To: | Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> |
Cc: | pgsql-bugs <pgsql-bugs(at)lists(dot)postgresql(dot)org> |
Subject: | Re:Re: BUG #17580: use pg_terminate_backend to terminate a wal senderprocess may wait a long time |
Date: | 2022-08-16 03:26:12 |
Message-ID: | tencent_8FF2C8F52B54DD943BAEC625E6A868756806@qq.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Thanks!
I will upgrade our version after it is fixed to 10.
Regards,
--
Whale Song
Original Email
Sender:"Masahiko Sawada"< sawada(dot)mshk(at)gmail(dot)com >;
Sent Time:2022/8/15 12:02
To:"WhaleSong"< 13207961(at)qq(dot)com >;
Cc recipient:"pgsql-bugs"< pgsql-bugs(at)lists(dot)postgresql(dot)org >;
Subject:Re: BUG #17580: use pg_terminate_backend to terminate a wal senderprocess may wait a long time
Hi,
On Mon, Aug 15, 2022 at 11:27 AM <13207961(at)qq(dot)com> wrote:
>
> Hi Masahiko,
> I think maybe you should use filter-tables to filter the test table, likes:
> filter-tables="public.test666"
>
Thanks, I could reproduce this issue with the option. And I've
confirmed this issue exists also in the latest minor version, 10.22,
and HEAD.
If the plugin filters out all changes, there is no place to check the
interruptions. So I think it makes sense to add CHECK_FOR_INTERRUPTS
to the main loop of processing logical change. It would be better to
do that on the core, rather than the plugin side. I've attached the
patch. I think we should backpatch to 10.
Regards,
--
Masahiko Sawada
EDB: https://www.enterprisedb.com/
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2022-08-16 06:58:07 | Re: No-op updates with partitioning and logical replication started failing in version 13 |
Previous Message | Peter Smith | 2022-08-16 02:59:43 | Re: No-op updates with partitioning and logical replication started failing in version 13 |