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