Re: Get memory contexts of an arbitrary backend process - Mailing list pgsql-hackers
From | Kasahara Tatsuhito |
---|---|
Subject | Re: Get memory contexts of an arbitrary backend process |
Date | |
Msg-id | CAP0=ZVKiHGqxLzUCZsUZshFbESP99aMNZ58b41oOf17qTB1Mbw@mail.gmail.com Whole thread Raw |
In response to | Get memory contexts of an arbitrary backend process (torikoshia <torikoshia@oss.nttdata.com>) |
Responses |
Re: Get memory contexts of an arbitrary backend process
|
List | pgsql-hackers |
Hi, On Mon, Aug 31, 2020 at 8:22 PM torikoshia <torikoshia@oss.nttdata.com> wrote: > As discussed in the thread[1], it'll be useful to make it > possible to get the memory contexts of an arbitrary backend > process. +1 > Attached PoC patch makes pg_get_backend_memory_contexts() > display meory contexts of the specified PID of the process. Thanks, it's a very good patch for discussion. > It doesn't display contexts of all the backends but only > the contexts of specified process. or we can "SELECT (pg_get_backend_memory_contexts(pid)).* FROM pg_stat_activity WHERE ...", so I don't think it's a big deal. > The rough idea of implementation is like below: > > 1. send a signal to the specified process > 2. signaled process dumps its memory contexts to a file > 3. read the dumped file and display it to the user I agree with the overview of the idea. Here are some comments and questions. - Currently, "the signal transmission for dumping memory information" and "the read & output of dump information " are on the same interface, but I think it would be better to separate them. How about providing the following three types of functions for users? - send a signal to specified pid - check the status of the signal sent and received - read the dumped information - How about managing the status of signal send/receive and dump operations on a shared hash or others ? Sending and receiving signals, dumping memory information, and referencing dump information all work asynchronously. Therefore, it would be good to have management information to check the status of each process. A simple idea is that .. - send a signal to dump to a PID, it first record following information into the shared hash. pid (specified pid) loc (dump location, currently might be ASAP) recv (did the pid process receive a signal? first false) dumped (did the pid process dump a mem information? first false) - specified process receive the signal, update the status in the shared hash, then dumped at specified location. - specified process finish dump mem information, update the status in the shared hash. - Does it allow one process to output multiple dump files? It appears to be a specification to overwrite at present, but I thought it would be good to be able to generate multiple dump files in different phases (e.g., planning phase and execution phase) in the future. - How is the dump file cleaned up? Best regards, -- Tatsuhito Kasahara kasahara.tatsuhito _at_ gmail.com
pgsql-hackers by date: