Re: Get memory contexts of an arbitrary backend process

Hi

po 31. 8. 2020 v 17:03 odesílatel Kasahara Tatsuhito <
kasahara(dot)tatsuhito(at)gmail(dot)com> napsal:

> Hi,
>
> On Mon, Aug 31, 2020 at 8:22 PM torikoshia <torikoshia(at)oss(dot)nttdata(dot)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
>
>
>