Re: Get memory contexts of an arbitrary backend process

Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>

From: Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: torikoshia <torikoshia@oss.nttdata.com>, PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2020-09-04T02:47:30Z
Lists: pgsql-hackers
On Fri, Sep 4, 2020 at 2:40 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com> writes:
> > Yes, but it's not only for future expansion, but also for the
> > usability and the stability of this feature.
> > For example, if you want to read one dumped file multiple times and analyze it,
> > you will want the ability to just read the dump.
>
> If we design it to make that possible, how are we going to prevent disk
> space leaks from never-cleaned-up dump files?
In my thought, with features such as a view that allows us to see a
list of dumped files,
it would be better to have a function that simply deletes the dump
files associated with a specific PID,
or to delete all dump files.
Some files may be dumped with unexpected delays, so I think the
cleaning feature will be necessary.
( Also, as the pgsql_tmp file, it might better to delete dump files
when PostgreSQL start.)

Or should we try to delete the dump file as soon as we can read it?

Best regards,

-- 
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com



Commits

  1. Add function to log the memory contexts of specified backend process.

  2. Add pg_backend_memory_contexts system view.

  3. Limit the verbosity of memory context statistics dumps.