Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
От | Kyotaro Horiguchi |
---|---|
Тема | Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time |
Дата | |
Msg-id | 20220823.130011.1417353052472533418.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time (Masahiko Sawada <sawada.mshk@gmail.com>) |
Ответы |
Re: BUG #17580: use pg_terminate_backend to terminate a wal sender process may wait a long time
|
Список | 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 по дате отправления: