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 ) id 1kAOsJ-0007zt-To for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Aug 2020 02:39:51 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1kAOsI-0001y0-Sg for pgsql-hackers@arkaria.postgresql.org; Tue, 25 Aug 2020 02:39:50 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAOsI-0001xe-M9 for pgsql-hackers@lists.postgresql.org; Tue, 25 Aug 2020 02:39:50 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAOsG-0008Px-D9 for pgsql-hackers@postgresql.org; Tue, 25 Aug 2020 02:39:50 +0000 Received: from hnk.local (p12054-ipngn2901funabasi.chiba.ocn.ne.jp [153.212.171.54]) by oss.nttdata.com (Postfix) with ESMTPSA id E7D3E60560; Tue, 25 Aug 2020 11:39:44 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.102.3 at oss.nttdata.com Subject: Re: Creating a function for exposing memory usage of backend process To: torikoshia Cc: Michael Paquier , Kasahara Tatsuhito , Andres Freund , Tom Lane , PostgreSQL-development , Robert Haas References: <261eebda3e1909475162b968e5a4ad2b@oss.nttdata.com> <66ae5b88-208d-96fa-c20a-fb539b597859@oss.nttdata.com> <20200819135545.GC19121@paquier.xyz> <1414992.1597849297@sss.pgh.pa.us> <20200819225343.c7rxteydi35nhrdp@alap3.anarazel.de> <1554676.1597886946@sss.pgh.pa.us> <20200820014301.5pr7qjugnvpovu62@alap3.anarazel.de> <20200822121641.GE2108@paquier.xyz> <07da4267-74bf-4a6b-3312-4ab7c1e72f66@oss.nttdata.com> From: Fujii Masao Message-ID: <2cfafd6e-8b4e-7b5c-3dca-ca474662d5ca@oss.nttdata.com> Date: Tue, 25 Aug 2020 11:39:44 +0900 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:68.0) Gecko/20100101 Thunderbird/68.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On 2020/08/24 21:56, torikoshia wrote: > On 2020-08-24 13:13, Fujii Masao wrote: >> On 2020/08/24 13:01, torikoshia wrote: >>> On 2020-08-22 21:18, Michael Paquier wrote: >>> >>> Thanks for reviewing! >>> >>>> On Fri, Aug 21, 2020 at 11:27:06PM +0900, torikoshia wrote: >>>>> OK. Added a regression test on sysviews.sql. >>>>> (0001-Added-a-regression-test-for-pg_backend_memory_contex.patch) >>>>> >>>>> Fujii-san gave us an example, but I added more simple one considering >>>>> the simplicity of other tests on that. >>>> >>>> What you have sent in 0001 looks fine to me.  A small test is much >>>> better than nothing. >> >> +1 >> >> But as I proposed upthread, what about a bit complicated test as follows, >> e.g., to confirm that the internal logic for level works expectedly? >> >>      SELECT name, ident, parent, level, total_bytes >= free_bytes FROM >> pg_backend_memory_contexts WHERE level = 0; > > OK! > Attached an updated patch. Thanks for updating the patch! Looks good to me. Barring any objection, I will commit this patch. > >> >> >>>> >>>>> Added a patch for relocating the codes to mcxtfuncs.c. >>>>> (patches/0001-Rellocated-the-codes-for-pg_backend_memory_contexts-.patch) >> >> Thanks for the patch! Looks good to me. >> Barring any objection, I will commit this patch at first. >> >> >>>> >>>> The same code is moved around line-by-line. >>>> >>>>> Of course, this restriction makes pg_backend_memory_contexts hard to use >>>>> when the user of the target session is not granted pg_monitor because the >>>>> scope of this view is session local. >>>>> >>>>> In this case, I imagine additional operations something like temporarily >>>>> granting pg_monitor to that user. >>>> >>>> Hmm.  I am not completely sure either that pg_monitor is the best fit >>>> here, because this view provides information about a bunch of internal >>>> structures.  Something that could easily be done though is to revoke >>>> the access from public, and then users could just set up GRANT >>>> permissions post-initdb, with pg_monitor as one possible choice. This >>>> is the safest path by default, and this stuff is of a caliber similar >>>> to pg_shmem_allocations in terms of internal contents. >>> >>> I think this is a better way than what I did in >>> 0001-Rellocated-the-codes-for-pg_backend_memory_contexts-.patch. >> >> You mean 0001-Restrict-the-access-to-pg_backend_memory_contexts-to.patch? > > Oops, I meant 0001-Restrict-the-access-to-pg_backend_memory_contexts-to.patch. This patch also looks good to me. Thanks! Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATION