MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII;
 format=flowed
Content-Transfer-Encoding: 7bit
Date: Thu, 10 Sep 2020 20:53:53 +0900
From: torikoshia <torikoshia@oss.nttdata.com>
To: "Tomas Vondra <tomas.vondra@2ndquadrant.com>Kasahara Tatsuhito"
 <kasahara.tatsuhito@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL-development
 <pgsql-hackers@postgresql.org>
Subject: Re: Get memory contexts of an arbitrary backend process
In-Reply-To: <20200904124619.k2dgu7dty7awb6cu@development>
References: <0271f440ac77f2a4180e0e56ebd944d1@oss.nttdata.com>
 <CAP0=ZVKiHGqxLzUCZsUZshFbESP99aMNZ58b41oOf17qTB1Mbw@mail.gmail.com>
 <CAFj8pRCZK_QgnRufy43Qjc_Mfuww-Y8eCPG5WY5Xe-Hat0LLTw@mail.gmail.com>
 <4a39f13d6496ea4686bbac4254154fe8@oss.nttdata.com>
 <CAP0=ZV+6A8wvtZw+Ss9Lho5OfbRJ8_CiP96GHm503Uv4+=6kHg@mail.gmail.com>
 <640735.1599154807@sss.pgh.pa.us>
 <CAP0=ZVK_FFijULfQWD87GriDKgD+S3HdgWhvyjPLxNiaGHrB3Q@mail.gmail.com>
 <20200904124619.k2dgu7dty7awb6cu@development>
Message-ID: <8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com>
User-Agent: Roundcube Webmail/1.1.9
Precedence: bulk

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@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?
>> 
> 
> 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