Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: thomas(dot)munro(at)gmail(dot)com
Cc: tgl(at)sss(dot)pgh(dot)pa(dot)us, andres(at)anarazel(dot)de, denis(dot)patron(at)previnet(dot)it, pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Date: 2020-10-15 01:42:48
Message-ID: 20201015.104248.2052383383680508195.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-hackers

Ouch. You beat me to it.

At Thu, 15 Oct 2020 14:26:36 +1300, Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote in
> On Thu, Oct 15, 2020 at 8:15 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Thomas Munro <thomas(dot)munro(at)gmail(dot)com> writes:
> > > On Wed, Oct 14, 2020 at 5:35 PM Andres Freund <andres(at)anarazel(dot)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

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Sandeep Thakkar 2020-10-15 02:37:24 Re: Checksum verification fails with StackBuilder when downloading pgAgent
Previous Message Thomas Munro 2020-10-15 01:26:36 Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-10-15 01:43:26 Re: jit and explain nontext
Previous Message Thomas Munro 2020-10-15 01:26:36 Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted