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 1u78ja-00B7CW-Cm for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Apr 2025 08:12:03 +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 1u78jX-00CHhx-4b for pgsql-hackers@arkaria.postgresql.org; Tue, 22 Apr 2025 08:11:59 +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 1u78jW-00CHhp-QN for pgsql-hackers@lists.postgresql.org; Tue, 22 Apr 2025 08:11:59 +0000 Received: from meldrar.postgresql.org ([2a02:c0:301:0:ffff::31]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u78jU-001N50-0V for pgsql-hackers@lists.postgresql.org; Tue, 22 Apr 2025 08:11:59 +0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=postgresql.org; s=20171124; h=To:References:Message-Id: Content-Transfer-Encoding:Cc:Date:In-Reply-To:From:Subject:Mime-Version: Content-Type:Sender:Reply-To:Content-ID:Content-Description; bh=asxOS5wuC12MzdwJ3+I8GXMTqSHOKcNhtHJO8Nn8JM8=; b=l2p9DGoxTR5icyJbCtIDmNrDA7 PjuD8v7DgzD6mIXmyb1AEpG/pReWt4P2wjSwZgbZ5RFfTvp4rELZ3lNVve7BAzlcJYZaNeKpnNqAR lzxp4P3CDK/5nFtIreshe0i+2cRdWr0IPZOao8ViX4e2qzO2M7x8+qDOpnoTuh63c8udSPWThnlof PtPV8ZgX62e0GinnGnqLw3TSxKW/ExTxxs8WCUT52nq5spjaQFkrMZIERRk/KumfR+6uGzpOiFAZY UvvKTrTtRJERnNI3tVzEQE8gvdvTkC14xmJydoW62e2b66PW4LKdvb5/6NOPM69tRYhV/x5fRyPcW A4P2QVqQ==; Received: from [90.229.0.9] (helo=smtpclient.apple) by meldrar.postgresql.org with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1u78jS-0046Y8-0P; Tue, 22 Apr 2025 08:11:56 +0000 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) Subject: Re: pgsql: Add function to get memory context stats for processes From: Daniel Gustafsson In-Reply-To: Date: Tue, 22 Apr 2025 10:11:43 +0200 Cc: Andres Freund , PostgreSQL Hackers , Rahila Syed Content-Transfer-Encoding: quoted-printable Message-Id: <8EBFBFBC-DAC2-4521-AE16-069F7FD8EFBC@postgresql.org> References: To: Robert Haas X-Mailer: Apple Mail (2.3776.700.51.11.1) X-Host-Lookup-Failed: Reverse DNS lookup failed for 90.229.0.9 (failed) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk > On 17 Apr 2025, at 16:42, Robert Haas wrote: >=20 > On Tue, Apr 15, 2025 at 6:11=E2=80=AFAM Andres Freund = wrote: >> There very well could be a CFI - but it better be somewhere where the >> in-memory state is consistent. Otherwise an error inside raised in = the CFI >> would lead the in-memory state inconsistent which then would cause = problems >> when cleaning up the dsa during resowner release or process exit. >>=20 >> What am I missing here? >=20 > I think maybe you're only thinking about gathering the data. What > about publishing it? If the DSA code were interrupted at a CFI and the > interrupting code went and tried to perform a DSA allocation to store > the resulting data and then returned to the interrupted DSA operation, > would you expect the code to cope with that? I do not believe we have > anywhere enough guarantees about reentrancy for that to be safe. Do you mean that an interrupt handler will make DSA allocations? I = don't think that would be something we'd want to allow regardless of this patch. Or = did I misunderstand the above? -- Daniel Gustafsson