Re: Unresolved repliaction hang and stop problem.
От | Kyotaro Horiguchi |
---|---|
Тема | Re: Unresolved repliaction hang and stop problem. |
Дата | |
Msg-id | 20210618.145223.546668375832429315.horikyota.ntt@gmail.com обсуждение исходный текст |
Ответ на | Re: Unresolved repliaction hang and stop problem. (Alvaro Herrera <alvherre@alvh.no-ip.org>) |
Ответы |
Re: Unresolved repliaction hang and stop problem.
|
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: