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

From Thomas Munro
Subject Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted
Date
Msg-id CA+hUKGLj0jzP4vSq0unHPcaMMWGfmmcyhqmpFhar6G+Q_+LcUw@mail.gmail.com
Whole thread Raw
In response to Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Andres Freund <andres@anarazel.de>)
Responses Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
On Wed, Oct 14, 2020 at 5:35 PM Andres Freund <andres@anarazel.de> wrote:
> On 2020-10-14 12:05:10 +0900, Kyotaro Horiguchi wrote:
> > At the time a relation including an index is dropped, the first
> > segment file (named as "<id>" without a suffix number) is left behind
> > so the file is not shown as "(deleted)" in lsof output.
>
> 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.



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #16670: pgstattuple ERROR: relation "sql_implementation_info" does not exist
Next
From: Tom Lane
Date:
Subject: Re: BUG #16663: DROP INDEX did not free up disk space: idle connection hold file marked as deleted