From: Tom Lane <tgl@sss.pgh.pa.us>
To: Thomas Munro <thomas.munro@gmail.com>
cc: Andres Freund <andres@anarazel.de>,
        Kyotaro Horiguchi <horikyota.ntt@gmail.com>, denis.patron@previnet.it,
        PostgreSQL mailing lists <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: 
 <CA+hUKGLj0jzP4vSq0unHPcaMMWGfmmcyhqmpFhar6G+Q_+LcUw@mail.gmail.com>
References: <16663-fe97ccf9932fc800@postgresql.org>
 <20201014.120510.184391841712786310.horikyota.ntt@gmail.com>
 <20201014043540.6etouknbpqqiqj7t@alap3.anarazel.de>
 <CA+hUKGLj0jzP4vSq0unHPcaMMWGfmmcyhqmpFhar6G+Q_+LcUw@mail.gmail.com>
Comments: In-reply-to Thomas Munro <thomas.munro@gmail.com>
	message dated "Thu, 15 Oct 2020 08:08:06 +1300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <3624716.1602702898.1@sss.pgh.pa.us>
Date: Wed, 14 Oct 2020 15:14:58 -0400
Message-ID: <3624717.1602702898@sss.pgh.pa.us>
Precedence: bulk

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.

			regards, tom lane