On Fri, Jun 18, 2021 at 11:22 AM Kyotaro Horiguchi
<horikyota.ntt@gmail.com> wrote:
>
> 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?
>
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.
