Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u53cY-00BVH5-Tb for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Apr 2025 14:20:11 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1u53cX-00Fs90-5L for pgsql-hackers@arkaria.postgresql.org; Wed, 16 Apr 2025 14:20:09 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u53cW-00Fs7l-Rz for pgsql-hackers@lists.postgresql.org; Wed, 16 Apr 2025 14:20:09 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u53cU-000PCD-00 for pgsql-hackers@postgresql.org; Wed, 16 Apr 2025 14:20:09 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTPA id 98663619C1; Wed, 16 Apr 2025 23:20:00 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Date: Wed, 16 Apr 2025 23:19:59 +0900 From: torikoshia To: Daniel Gustafsson , dgrowleyml@gmail.com Cc: PostgreSQL Hackers Subject: Re: Align memory context level numbering in pg_log_backend_memory_contexts() In-Reply-To: <81B10568-B4A1-46C0-9809-2F8E06AB8C7B@yesql.se> References: <395ea5d4fe190480efa95bf533485c70@oss.nttdata.com> <81B10568-B4A1-46C0-9809-2F8E06AB8C7B@yesql.se> User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: torikoshia@oss.nttdata.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 2025-04-16 06:18, Daniel Gustafsson wrote: >> On 15 Apr 2025, at 23:03, David Rowley wrote: > >> My vote is to make the levels 1-based in all locations where we output >> the context information. > > I agree with this, pg_get_process_memory_contexts() also use 1-based > levels > fwiw. +1. I believe there's no particular issue with starting the level from 1 in pg_log_backend_memory_contexts(). Regarding the implementation: In the initial patch attached, I naïvely incremented the level just before emitting the log line. However, it might be cleaner to simply initialize the level variable to 1 from the start. This could help avoid unnecessary confusion when debugging that part of the code. Similarly, I noticed that in pg_get_process_memory_contexts(), the level is initialized to 0 in ProcessGetMemoryContextInterrupt(void): int level = 0; .. MemoryContextStatsInternal(c, level, 100, 100, &grand_totals, .. If we want to be consistent, perhaps it would make sense to start from 1 there as well. BTW level variable has existed since before pg_backend_memory_contexts was introduced — it was originally used for functions that help inspect memory contexts via the debugger. Because of that, I think changing this would affect not only these functions codes but some older ones. -- Atsushi Torikoshi Seconded from NTT DATA GROUP CORPORATION to SRA OSS K.K.