pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Fujii Masao <masao.fujii@oss.nttdata.com>
To: torikoshia <torikoshia@oss.nttdata.com>
To: Andres Freund <andres@anarazel.de>
Cc: pgsql-hackers@postgresql.org
Subject: Re: Creating a function for exposing memory usage of backend process
Date: Mon, 13 Jul 2020 13:00:22 +0900
Message-ID: <0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com> (raw)
In-Reply-To: <24ea05d7bbdb652feef50caee6fcfbf8@oss.nttdata.com>
References: <78268b5f-53ed-4645-1abb-23c1030cce0a@oss.nttdata.com>
	<6c828f3a1d44dba81999fc7990b8f1c5@oss.nttdata.com>
	<e068e42d-8eda-fbe5-e84c-7188e9386778@oss.nttdata.com>
	<062bab2db5645812fae12e3a965de463@oss.nttdata.com>
	<5cbed0cc-79fc-3b98-120a-20e07848d10a@oss.nttdata.com>
	<805313b5f7dc2e6c19b209ff930a7a61@oss.nttdata.com>
	<a9d68488-8343-5d70-4612-311d597f9962@oss.nttdata.com>
	<cd0e961fd42e5708fdea70f7420bf214@oss.nttdata.com>
	<9ee242b1-9e70-18f5-0033-6a086e71164d@oss.nttdata.com>
	<3548926512ddfaedfb5eaf967bf2f196@oss.nttdata.com>
	<20200708170348.rsqry4b4k5mrsu7y@alap3.anarazel.de>
	<24ea05d7bbdb652feef50caee6fcfbf8@oss.nttdata.com>



On 2020/07/10 17:32, torikoshia wrote:
> On 2020-07-09 02:03, Andres Freund wrote:
>> Hi,
>>
>> I think this is an incredibly useful feature.
> 
> Thanks for your kind comments and suggestion!
> 
> 
>> On 2020-07-07 22:02:10 +0900, torikoshia wrote:
>>> > There can be multiple memory contexts with the same name. So I'm afraid
>>> > that it's difficult to identify the actual parent memory context from
>>> > this
>>> > "parent" column. This is ok when logging memory contexts by calling
>>> > MemoryContextStats() via gdb. Because child memory contexts are printed
>>> > just under their parent, with indents. But this doesn't work in the
>>> > view.
>>> > To identify the actual parent memory or calculate the memory contexts
>>> > tree
>>> > from the view, we might need to assign unique ID to each memory context
>>> > and display it. But IMO this is overkill. So I'm fine with current
>>> > "parent"
>>> > column. Thought? Do you have any better idea?
>>>
>>> Indeed.
>>> I also feel it's not usual to assign a unique ID, which
>>> can vary every time the view displayed.
>>
>> Hm. I wonder if we just could include the address of the context
>> itself. There might be reasons not to do so (e.g. security concerns
>> about leaked pointers making attacks easier), but I think it's worth
>> considering.
> 
> 
> I tried exposing addresses of each context and their parent.
> Attached a poc patch.
> 
>    =# SELECT name, address, parent_address, total_bytes FROM pg_backend_memory_contexts ;
> 
>             name           |  address  | parent_address | total_bytes
>    --------------------------+-----------+----------------+-------------
>     TopMemoryContext         | 0x1280da0 |                |       80800
>     TopTransactionContext    | 0x1309040 | 0x1280da0      |        8192
>     Prepared Queries         | 0x138a480 | 0x1280da0      |       16384
>     Type information cache   | 0x134b8c0 | 0x1280da0      |       24624
>     ...
>     CacheMemoryContext       | 0x12cb390 | 0x1280da0      |     1048576
>     CachedPlanSource         | 0x13c47f0 | 0x12cb390      |        4096
>     CachedPlanQuery          | 0x13c9ae0 | 0x13c47f0      |        4096
>     CachedPlanSource         | 0x13c7310 | 0x12cb390      |        4096
>     CachedPlanQuery          | 0x13c1230 | 0x13c7310      |        4096
>     ...
> 
> 
> Now it's possible to identify the actual parent memory context even when
> there are multiple memory contexts with the same name.
> 
> I'm not sure, but I'm also worrying about this might incur some security
> related problems..
> 
> I'd like to hear more opinions about:
> 
> - whether information for identifying parent-child relation is necessary or it's an overkill
> - if this information is necessary, memory address is suitable or other means like assigning unique numbers are required

To consider this, I'd like to know what security issue can actually
happen when memory addresses are exposed. I have no idea about this..

Regards,


-- 
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION





view thread (57+ messages)  latest in thread

Message-ID: <0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com>
Permalink:  ../0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com/
Also on:    postgresql.org/message-id/0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com

 · 

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: masao.fujii@oss.nttdata.com, torikoshia@oss.nttdata.com, andres@anarazel.de
  Subject: Re: Creating a function for exposing memory usage of backend process
  In-Reply-To: <0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox