Re: Creating a function for exposing memory usage of backend process

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Creating a function for exposing memory usage of backend process
Date: 2020-07-13 04:00:22
Message-ID: 0aede2b4-8d24-4923-522d-f06cef8302e9@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Andrey V. Lepikhov 2020-07-13 04:41:12 Re: POC and rebased patch for CSN based snapshots
Previous Message Bharath Rupireddy 2020-07-13 03:16:57 Re: [PATCH] Performance Improvement For Copy From Binary Files