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.