Re: Get memory contexts of an arbitrary backend process
От | Fujii Masao |
---|---|
Тема | Re: Get memory contexts of an arbitrary backend process |
Дата | |
Msg-id | 5b190984-5b6a-30ce-088a-85ba1af2cfdd@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: Get memory contexts of an arbitrary backend process (Fujii Masao <masao.fujii@oss.nttdata.com>) |
Ответы |
Re: Get memory contexts of an arbitrary backend process
|
Список | pgsql-hackers |
On 2021/03/26 12:26, Fujii Masao wrote: > > > On 2021/03/26 12:01, Kyotaro Horiguchi wrote: >> At Thu, 25 Mar 2021 23:45:17 +0900, torikoshia <torikoshia@oss.nttdata.com> wrote in >>> Attached new one. > > Regarding the argument max_children, isn't it better to set its default value, > e.g., 100 like MemoryContextStats() uses? + mcxtLogData->maxChildrenPerContext = max_children; + + if(!SendProcSignal(pid, PROCSIG_LOG_MEMORY_CONTEXT, proc->backendId)) + PG_RETURN_BOOL(true); Do we need memory barrier here? Otherwise, there is a race condition where maxChildrenPerContext has not been set yet when the target backend that received signal read that shared variable. No? + Note that when multiple + <function>pg_get_backend_memory_contexts</function> called in + succession or simultaneously, <parameter>max_children</parameter> can + be the one of another + <function>pg_get_backend_memory_contexts</function>. + </para></entry> This might not be an issue in practice as Horiguchi-san said upthread. But this looks a bit ugly and might be footgun later. The current approach using shared memory to pass this information to the target backends might be overkill, and too complicated to polish the design at the stage just before feature freeze. So I'd withdraw my previous comment and am OK to use the hard-coded value as max_children at the first version of this feature. Thought? Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION
В списке pgsql-hackers по дате отправления: