Hi, On Thu, Sep 10, 2020 at 8:53 PM torikoshia <torikos...@oss.nttdata.com> wrote: > > 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 <t...@sss.pgh.pa.us> wrote: > >>> Kasahara Tatsuhito <kasahara.tatsuh...@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. Yeah, it might be better to avoid making the user responsible for removal.
I think it's fine to have an interface to delete in an emergency, but I agree that users shouldn't be made aware of the existence or deletion of dump files, basically. > +1. > If there are no other objections, I'm going to accept this > suggestion. So +1 Best regards, -- Tatsuhito Kasahara kasahara.tatsuhito _at_ gmail.com