From: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com> |
---|---|
To: | Michael Paquier <michael(at)paquier(dot)xyz>, Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>, Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Robert Haas <robertmhaas(at)gmail(dot)com> |
Subject: | Re: Creating a function for exposing memory usage of backend process |
Date: | 2020-08-24 04:01:42 |
Message-ID: | c9515ae497b4a077360a31547782acb8@oss.nttdata.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
>
>> 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.
I think this is a better way than what I did in
0001-Rellocated-the-codes-for-pg_backend_memory_contexts-.patch.
Attached a patch.
>
> 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
On 2020/08/20 2:59, Kasahara Tatsuhito wrote:
>>> I totally agree that it's not *enough*, but in contrast to you I
>>> think
>>> it's a good step. Subsequently we should add a way to get any
>>> backends
>>> memory usage.
>>> It's not too hard to imagine how to serialize it in a way that can be
>>> easily deserialized by another backend. I am imagining something like
>>> sending a procsignal that triggers (probably at CFR() time) a backend
>>> to
>>> write its own memory usage into pg_memusage/<pid> or something
>>> roughly
>>> like that.
>>
>> Sounds good. Maybe we can also provide the SQL-callable function
>> or view to read pg_memusage/<pid>, to make the analysis easier.
> +1
I'm thinking about starting a new thread to discuss exposing other
backend's memory context.
Regards,
--
Atsushi Torikoshi
NTT DATA CORPORATION
Attachment | Content-Type | Size |
---|---|---|
0001-Previously-pg_backend_memory_contexts-doesn-t-have-a.patch | text/x-diff | 1.7 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2020-08-24 04:12:42 | Re: list of extended statistics on psql |
Previous Message | Tatsuro Yamada | 2020-08-24 03:22:49 | list of extended statistics on psql |