Horton

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

Thomas Munro <thomas.munro@gmail.com>

View thread View on postgr.es
From: Thomas Munro <thomas.munro@gmail.com>
To: Andres Freund <andres@anarazel.de>
Cc: Kyotaro Horiguchi <horikyota.ntt@gmail.com>, denis.patron@previnet.it, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2020-10-14T19:08:06Z
Lists: pgsql-bugs, pgsql-hackers 
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.

Commits

  1. Use truncate(2) where appropriate.

  2. Free disk space for dropped relations on commit.

  3. Rename the "point is strictly above/below point" comparison operators.