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

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: sawada(dot)mshk(at)gmail(dot)com
Cc: 13207961(at)qq(dot)com, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
Date: 2022-08-23 04:00:11
Message-ID: 20220823.130011.1417353052472533418.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

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.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Amit Kapila 2022-08-23 11:00:05 Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
Previous Message Bruce Momjian 2022-08-22 16:02:04 Re: BUG #17233: Incorrect behavior of DELETE command with bad subquery in WHERE clause