Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time

On Tue, Aug 23, 2022 at 9:30 AM Kyotaro Horiguchi
<horikyota(dot)ntt(at)gmail(dot)com> wrote:
>
> At Mon, 15 Aug 2022 13:02:59 +0900, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com> wrote in
> > 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
>
> 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.
>

BTW, I have pushed a patch for this, see [1]. I am not sure whether it
is a good idea to add a comment there but anyway if others also feel
the same then I am okay with it.

[1] - https://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=f972ec5c285c3bc50d81f8044e08cd636017ab68

--
With Regards,
Amit Kapila.