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

Поиск
Список
Период
Сортировка
От torikoshia
Тема Re: Creating a function for exposing memory usage of backend process
Дата
Msg-id e1b81c88dc750ecd2ef03924af751567@oss.nttdata.com
обсуждение исходный текст
Ответ на Re: Creating a function for exposing memory usage of backend process  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Ответы Re: Creating a function for exposing memory usage of backend process  (Robert Haas <robertmhaas@gmail.com>)
Re: Creating a function for exposing memory usage of backend process  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Список pgsql-hackers
On 2020-07-30 15:13, Kasahara Tatsuhito wrote:
> Hi,
> 
> On Fri, Jul 10, 2020 at 5:32 PM torikoshia <torikoshia@oss.nttdata.com> 
> wrote:
>> - whether information for identifying parent-child relation is 
>> necessary
>> or it's an overkill
> I think it's important to understand the parent-child relationship of
> the context.
> Personally, I often want to know the following two things ..
> 
> - In which life cycle is the target context? (Remaining as long as the
> process is living? per query?)
> - Does the target context belong to the correct (parent) context?
> 
>> - if this information is necessary, memory address is suitable or 
>> other
>> means like assigning unique numbers are required
> IMO, If each context can be uniquely identified (or easily guessed) by
> "name" and "ident",
> then I don't think the address information is necessary.
> Instead, I like the way that directly shows the context name of the
> parent, as in the 0005 patch.

Thanks for your opinion!

I also feel it'll be sufficient to know not the exact memory context
of the parent but the name of the parent context.

And as Fujii-san told me in person, exposing memory address seems
not preferable considering there are security techniques like
address space layout randomization.



> On 2020-07-10 08:30:22 +0900, torikoshia wrote:
>> On 2020-07-08 22:12, Fujii Masao wrote:

>> Another comment about parent column is: dynahash can be parent?
>> If yes, its indent instead of name should be displayed in parent
>> column?

> I'm not sure yet, but considering the changes in the future, it seems
> better to do so.

Attached a patch which displays ident as parent when dynahash is a
parent.

I could not find the case when dynahash can be a parent so I tested it
using attached test purposed patch.


Regards,

--
Atsushi Torikoshi
NTT DATA CORPORATION
Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Daniel Gustafsson
Дата:
Сообщение: Re: Ought to use heap_multi_insert() for pg_attribute/depend insertions?
Следующее
От: "matsumura.ryo@fujitsu.com"
Дата:
Сообщение: [bugfix]"make installcheck" could not work in PGXS