Re: Get memory contexts of an arbitrary backend process

On 2020-09-04 21:46, Tomas Vondra wrote:
> On Fri, Sep 04, 2020 at 11:47:30AM +0900, Kasahara Tatsuhito wrote:
>> 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?
>>
>
> IMO making the cleanup a responsibility of the users (e.g. by exposing
> the list of dumped files through a view and expecting users to delete
> them in some way) is rather fragile.
>
> I don't quite see what's the point of designing it this way. It was
> suggested this improves stability and usability of this feature, but
> surely making it unnecessarily complex contradicts both points?
>
> IMHO if the user needs to process the dump repeatedly, what's
> preventing
> him/her from storing it in a file, or something like that? At that
> point
> it's clear it's up to them to remove the file. So I suggest to keep the
> feature as simple as possible - hand the dump over and delete.

+1.
If there are no other objections, I'm going to accept this
suggestion.

Regards