Received: from malur.postgresql.org ([217.196.149.56])
	by arkaria.postgresql.org with esmtps
 (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1lPdTP-0007fY-Pq
	for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Mar 2021 03:49:23 +0000
Received: from localhost ([127.0.0.1] helo=malur.postgresql.org)
	by malur.postgresql.org with esmtp (Exim 4.92)
	(envelope-from <pgsql-hackers-owner+archive@lists.postgresql.org>)
	id 1lPdTO-00064g-OR
	for pgsql-hackers@arkaria.postgresql.org; Fri, 26 Mar 2021 03:49:22 +0000
Received: from makus.postgresql.org ([2001:4800:3e1:1::229])
	by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <masao.fujii@oss.nttdata.com>)
	id 1lPdTO-00064Z-I0
	for pgsql-hackers@lists.postgresql.org; Fri, 26 Mar 2021 03:49:22 +0000
Received: from oss.nttdata.com ([49.212.34.109])
	by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
	(Exim 4.92)
	(envelope-from <masao.fujii@oss.nttdata.com>)
	id 1lPdTM-000579-CU
	for pgsql-hackers@postgresql.org; Fri, 26 Mar 2021 03:49:21 +0000
Received: from hnk.local (p2350207-ipbf2126funabasi.chiba.ocn.ne.jp
 [114.167.184.207])
	by oss.nttdata.com (Postfix) with ESMTPSA id DB31362728;
	Fri, 26 Mar 2021 12:49:16 +0900 (JST)
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com
Subject: Re: Get memory contexts of an arbitrary backend process
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, torikoshia@oss.nttdata.com
Cc: pgsql-hackers@postgresql.org, tgl@sss.pgh.pa.us,
 gkokolatos@protonmail.com, kasahara.tatsuhito@gmail.com,
 craig@2ndquadrant.com
References: <0b0657d5febd0e46565a6bc9c62ba3f6@oss.nttdata.com>
 <2be9b430-e664-a342-7799-c92779808029@oss.nttdata.com>
 <a8af0d22d87a9fd3f5983d3c6db55b03@oss.nttdata.com>
 <20210326.120104.2148406039277091336.horikyota.ntt@gmail.com>
 <6738f309-a41b-cbe6-bb57-a1c58ce9f05a@oss.nttdata.com>
Message-ID: <5b190984-5b6a-30ce-088a-85ba1af2cfdd@oss.nttdata.com>
Date: Fri, 26 Mar 2021 12:49:16 +0900
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
 Gecko/20100101 Thunderbird/78.8.1
MIME-Version: 1.0
In-Reply-To: <6738f309-a41b-cbe6-bb57-a1c58ce9f05a@oss.nttdata.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
List-Id: <pgsql-hackers.lists.postgresql.org>
List-Help: <https://lists.postgresql.org/manage/>
List-Subscribe: <https://lists.postgresql.org/manage/>
List-Post: <mailto:pgsql-hackers@lists.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@lists.postgresql.org>
List-Archive: <https://www.postgresql.org/list/pgsql-hackers>
Archived-At: 
 <https://www.postgresql.org/message-id/5b190984-5b6a-30ce-088a-85ba1af2cfdd%40oss.nttdata.com>
Precedence: bulk



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