Re: Unresolved repliaction hang and stop problem.

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

In response to

Responses

Browse pgsql-hackers by date

  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