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