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. > Added a patch for relocating the codes to mcxtfuncs.c. > (patches/0001-Rellocated-the-codes-for-pg_backend_memory_contexts-.patch) 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. It seems to me that you are missing one "REVOKE ALL on pg_backend_memory_contexts FROM PUBLIC" in patch 0003. By the way, if that was just for me, I would remove used_bytes, which is just a computation from the total and free numbers. I'll defer that point to Fujii-san. -- Michael
signature.asc
Description: PGP signature
