From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | alvherre(at)alvh(dot)no-ip(dot)org |
Cc: | klasahubert(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org, amit(dot)kapila16(at)gmail(dot)com, lukasz(dot)biegaj(at)unitygroup(dot)com, krzysztof(dot)kois(at)unitygroup(dot)com |
Subject: | Re: Unresolved repliaction hang and stop problem. |
Date: | 2021-06-18 05:52:23 |
Message-ID: | 20210618.145223.546668375832429315.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Thu, 17 Jun 2021 12:56:42 -0400, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2021-06-18 05:57:18 | Re: Speed up pg_checksums in cases where checksum already set |
Previous Message | Michael Paquier | 2021-06-18 05:37:32 | Re: SSL/TLS instead of SSL in docs |