At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera <alvherre@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?
regards.
--
Kyotaro Horiguchi
NTT Open Source Software Center
