On Fri, Jun 18, 2021 at 11:22 AM Kyotaro Horiguchi <horikyota....@gmail.com> wrote: > > At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera <alvhe...@alvh.no-ip.org> > wrote in > > On 2021-Jun-17, Kyotaro Horiguchi wrote: > > > > > I don't see a call to hash_*seq*_search there. Instead, I see one in > > > ReorderBufferCheckMemoryLimit(). > > > > Doh, of course -- I misread. > > > > ReorderBufferCheckMemoryLimit is new in pg13 (cec2edfa7859) so now at > > least we have a reason why this workload regresses in pg13 compared to > > earlier releases. > > > > Looking at the code, it does seem that increasing the memory limit as > > Amit suggests might solve the issue. Is that a practical workaround? > > I believe so generally. I'm not sure about the op, though. > > Just increasing the working memory to certain size would solve the > problem. There might be a potential issue that it might be hard like > this case for users to find out that the GUC works for their issue (if > actually works). pg_stat_replicatoin_slots.spill_count / spill_txns > could be a guide for setting logical_decoding_work_mem. Is it worth > having additional explanation like that for the GUC variable in the > documentation? >
I don't see any harm in doing that but note that we can update it only for PG-14. The view pg_stat_replicatoin_slots is introduced in PG-14. -- With Regards, Amit Kapila.
