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 1u8mkg-00BYyF-Dk for pgsql-hackers@arkaria.postgresql.org; Sat, 26 Apr 2025 21:07:58 +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 1u8mkc-006qVy-SX for pgsql-hackers@arkaria.postgresql.org; Sat, 26 Apr 2025 21:07:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1u8mkc-006qVq-BB for pgsql-hackers@lists.postgresql.org; Sat, 26 Apr 2025 21:07:55 +0000 Received: from relay7-d.mail.gandi.net ([217.70.183.200]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u8mkZ-00277n-2Q for pgsql-hackers@lists.postgresql.org; Sat, 26 Apr 2025 21:07:53 +0000 Received: by mail.gandi.net (Postfix) with ESMTPSA id B2AA4438F0; Sat, 26 Apr 2025 21:07:47 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vondra.me; s=gm1; t=1745701668; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=SKEpTUriS7xluWxNg2zEXXFZTPoEXHn9XfUptV+EXFw=; b=FxzOMRgjgX0p8jseP19RqO2vDjv8E/CoBYbvlVg9wty509TH10j39/USEZ5LyTUOVQr2K4 jhCsaaEKMLbpttJOKGbt/jbN+5BTFR9uCb+VtswyikUGYoi3Wt4JNnuRIW0G2FaUftYPfK ajIdWM3HB8H30qKoiNYvGyz+gKtdmXaqW24vvX3VAmIOwXQ9XoQ7N8PWAIQwkRtBQ26TQH lLXhlyUSkGJm1njFIi2p4cWFNL6KR9F82xhMUfADzgxE42+5ooM/9c4rWccXp3Xk22yUAP EZWaubkjSm3aeKRQZr3/9q8NxwbbkGhlSj9YsX9GPb7tR6jWWNbyEEWnhxHt1A== Message-ID: <91f216ec-e367-42a5-8586-f554c4c28574@vondra.me> Date: Sat, 26 Apr 2025 23:07:46 +0200 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: pgsql: Add function to get memory context stats for processes To: Tom Lane , Robert Haas Cc: Daniel Gustafsson , Andres Freund , PostgreSQL Hackers , Rahila Syed References: <8EBFBFBC-DAC2-4521-AE16-069F7FD8EFBC@postgresql.org> <1428549.1745432074@sss.pgh.pa.us> Content-Language: en-US From: Tomas Vondra In-Reply-To: <1428549.1745432074@sss.pgh.pa.us> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-GND-State: clean X-GND-Score: -100 X-GND-Cause: gggruggvucftvghtrhhoucdtuddrgeefvddrtddtgddvheeivdefucetufdoteggodetrfdotffvucfrrhhofhhilhgvmecuifetpfffkfdpucggtfgfnhhsuhgsshgtrhhisggvnecuuegrihhlohhuthemuceftddunecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefkffggfgfuvfevfhfhjggtgfesthejredttddvjeenucfhrhhomhepvfhomhgrshcugghonhgurhgruceothhomhgrshesvhhonhgurhgrrdhmvgeqnecuggftrfgrthhtvghrnhepledugeeikefglefhgfffuedvleetteevgefhvdeikeefudduuddvhfevudefhfevnecukfhppeekiedrgeelrddvfedtrddvtdeinecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehinhgvthepkeeirdegledrvdeftddrvddtiedphhgvlhhopegluddtrddufeejrddtrddukegnpdhmrghilhhfrhhomhepthhomhgrshesvhhonhgurhgrrdhmvgdpnhgspghrtghpthhtohepiedprhgtphhtthhopehtghhlsehsshhsrdhpghhhrdhprgdruhhspdhrtghpthhtoheprhhosggvrhhtmhhhrggrshesghhmrghilhdrtghomhdprhgtphhtthhopegughhushhtrghfshhsohhnsehpohhsthhgrhgvshhqlhdrohhrghdprhgtphhtthhopegrnhgurhgvshesrghnrghrrgiivghlrdguvgdprhgtphhtthhopehpghhsqhhlqdhhrggtkhgvrhhssehlihhsthhsrdhpohhsthhgrhgvshhqlhdrohhrghdprhgtphhtthhopehrrghhi hhlrghshigvugeltdesghhmrghilhdrtghomh X-GND-Sasl: tomas@vondra.me List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 4/23/25 20:14, Tom Lane wrote: > Robert Haas writes: >> My primary concern about the patch is that >> ProcessGetMemoryContextInterrupt() can be called from any >> CHECK_FOR_INTERRUPTS() and calls lots of DSA functions, including >> dsa_create() and, via PublishMemoryContext(), dsa_allocate0(). I'm >> shocked to hear that you and Andres think that's safe to do at any >> current or future CHECK_FOR_INTERRUPTS() anywhere in the code; but >> Andres seems very confident that it's fine, so perhaps I should just >> stop worrying and be happy that we have the feature. > > Just for the record, it sounds quite unsafe to me too. I could > credit it being all right to examine the process' MemoryContext data > structures, but calling dsa_create() from CFI seems really insane. > Way too many moving parts there. > Maybe I'm oblivious to some very obvious issues, but why is this so different from everything else that is already called from ProcessInterrupts()? Perhaps dsa_create() is more complex compared to the other stuff (haven't checked), but why would it be unsafe? The one risk I can think of is a risk of recursion - if any of the functions called from ProcessGetMemoryContextInterrupt() does CFI, could that be a problem if there's another pending signal. I see some other handlers (e.g. ProcessParallelApplyMessages) handle this by explicitly holding interrupts. Should ProcessGetMemoryContextInterrupt() do the same thing? In any case, if DSA happens to not be the right way to transfer this, what should we use instead? The only thing I can think of is some sort of pre-allocated chunk of shared memory. regards -- Tomas Vondra