From: Kyotaro Horiguchi <horikyota.ntt@gmail.com>
To: thomas.munro@gmail.com
Cc: tgl@sss.pgh.pa.us
Cc: andres@anarazel.de
Cc: denis.patron@previnet.it
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Date: Thu, 15 Oct 2020 10:42:48 +0900 (JST)
Message-ID: <20201015.104248.2052383383680508195.horikyota.ntt@gmail.com> (raw)
In-Reply-To: <CA+hUKGJUM4CihcbcifKWYaxCbxkuEzGb0-2VU6G0oEwSog3=Xg@mail.gmail.com>
References: <CA+hUKGLj0jzP4vSq0unHPcaMMWGfmmcyhqmpFhar6G+Q_+LcUw@mail.gmail.com>
<3624717.1602702898@sss.pgh.pa.us>
<CA+hUKGJUM4CihcbcifKWYaxCbxkuEzGb0-2VU6G0oEwSog3=Xg@mail.gmail.com>
Ouch. You beat me to it.
At Thu, 15 Oct 2020 14:26:36 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in
> On Thu, Oct 15, 2020 at 8:15 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> > Thomas Munro <thomas.munro@gmail.com> writes:
> > > On Wed, Oct 14, 2020 at 5:35 PM Andres Freund <andres@anarazel.de> wrote:
> > >> I think we should consider either occasionally sending a sinval catchup
> > >> interrupt to backends that have been idle for a while, or to use a timer
> > >> that we use to limit the maximum time until we process sinvals. Just
> > >> having to wait till all backends become busy and process sinval events
> > >> doesn't really seem like good approach to me.
> >
> > > Oops, I also replied to this but now I see that I accidentally replied
> > > only to Horiguchi-san and not the list! I was thinking that we should
> > > perhaps consider truncating the files to give back the disk space (as
> > > we do for the first segment), so that it doesn't matter so much how
> > > long other backends take to process SHAREDINVALSMGR_ID, close their
> > > descriptors and release the inode.
> >
> > +1, I was also thinking that. It'd be pretty easy to fit into the
> > existing system structure (I think, without having looked at the relevant
> > code lately), and it would not add any overhead to normal processing.
> > Installing a timeout to handle this per Andres' idea inevitably *would*
> > add overhead.
>
> Alright, here is a first swing at making our behaviour more consistent
> in two ways:
>
> 1. The first segment should be truncated even in recovery.
> 2. Later segments should be truncated on commit.
>
> I don't know why the existing coding decides not to try to unlink the
> later segments if the truncate of segment 0 failed. We already
> committed, we should plough on.
I was trying the almost the same thing except how to emit the error
message for truncation and not trying to unlink if truncation ends
with ENOENT for following segments.
regareds.
--
Kyotaro Horiguchi
NTT Open Source Software Center
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-bugs@postgresql.org
Cc: horikyota.ntt@gmail.com, thomas.munro@gmail.com, tgl@sss.pgh.pa.us, andres@anarazel.de, denis.patron@previnet.it, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
In-Reply-To: <20201015.104248.2052383383680508195.horikyota.ntt@gmail.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