Re: Creating a function for exposing memory usage of backend process - Mailing list pgsql-hackers

From Fujii Masao
Subject Re: Creating a function for exposing memory usage of backend process
Date
Msg-id 0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com
Whole thread Raw
In response to Re: Creating a function for exposing memory usage of backend process  (torikoshia <torikoshia@oss.nttdata.com>)
List pgsql-hackers

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



pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: [PATCH] Performance Improvement For Copy From Binary Files
Next
From: "Andrey V. Lepikhov"
Date:
Subject: Re: POC and rebased patch for CSN based snapshots