sob., 19 cze 2021 o 12:14 Amit Kapila <amit.kapila16@gmail.com> napisał(a):
>
> 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.
We increased logical_decoding_work_mem for our production database
from 64 to 192 MB and it looks like the issue still persists. The
frequency with which replication hangs has remained the same. Do you
need any additional perf reports after our change?
--
Regards,
Hubert Klasa.