Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time - Mailing list pgsql-bugs

From Kyotaro Horiguchi
Subject Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
Date
Msg-id 20220823.130011.1417353052472533418.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time  (Masahiko Sawada <sawada.mshk@gmail.com>)
Responses Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
List pgsql-bugs
At Mon, 15 Aug 2022 13:02:59 +0900, Masahiko Sawada <sawada.mshk@gmail.com> wrote in 
> Hi,
> 
> On Mon, Aug 15, 2022 at 11:27 AM 巨鲸 <13207961@qq.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

Agreed. It is not sensible to put the responsibility to call CFI on
output plugins when it returns shortly.

> do that on the core, rather than the plugin side. I've attached the
> patch. I think we should backpatch to 10.

I might want to add a comment like "Do not rely on
CHECK_FOR_INTERRUPTS() calls by output plugins". Otherwise it is fine
with me.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center

pgsql-bugs by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause
Next
From: Amit Kapila
Date:
Subject: Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time