From: | Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | torikoshia <torikoshia(at)oss(dot)nttdata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Get memory contexts of an arbitrary backend process |
Date: | 2020-09-04 02:47:30 |
Message-ID: | CAP0=ZVK_FFijULfQWD87GriDKgD+S3HdgWhvyjPLxNiaGHrB3Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Fri, Sep 4, 2020 at 2:40 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | tsunakawa.takay@fujitsu.com | 2020-09-04 02:50:10 | RE: New statistics for tuning WAL buffer size |
Previous Message | Justin Pryzby | 2020-09-04 02:43:51 | Re: Allow CLUSTER, VACUUM FULL and REINDEX to change tablespace on the fly |