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: