pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: torikoshia <torikoshia@oss.nttdata.com>
To: "Tomas Vondra <tomas.vondra@2ndquadrant.com>
To: Kasahara Tatsuhito" <kasahara.tatsuhito@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Get memory contexts of an arbitrary backend process
Date: Thu, 10 Sep 2020 20:53:53 +0900
Message-ID: <8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com> (raw)
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>

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





view thread (52+ messages)  latest in thread

Message-ID: <8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com>
Permalink:  ../8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com/
Also on:    postgresql.org/message-id/8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: torikoshia@oss.nttdata.com, tomas.vondra@2ndquadrant.com, kasahara.tatsuhito@gmail.com, tgl@sss.pgh.pa.us
  Subject: Re: Get memory contexts of an arbitrary backend process
  In-Reply-To: <8865138e1c262d54e8a67a71b4a538aa@oss.nttdata.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox