Re: Get memory contexts of an arbitrary backend process - Mailing list pgsql-hackers
From | Pavel Stehule |
---|---|
Subject | Re: Get memory contexts of an arbitrary backend process |
Date | |
Msg-id | CAFj8pRCZK_QgnRufy43Qjc_Mfuww-Y8eCPG5WY5Xe-Hat0LLTw@mail.gmail.com Whole thread Raw |
In response to | Re: Get memory contexts of an arbitrary backend process (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>) |
Responses |
Re: Get memory contexts of an arbitrary backend process
|
List | pgsql-hackers |
Hi
po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com> napsal:
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?
For a very long time there has been similar discussion about taking session query and session execution plans from other sessions.
I am not sure how necessary information is in the memory dump, but I am sure so taking the current execution plan and complete text of the current query is pretty necessary information.
but can be great so this infrastructure can be used for any debugging purpose.
Regards
Pavel
Best regards,
--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com
pgsql-hackers by date: