Ouch. You beat me to it.
At Thu, 15 Oct 2020 14:26:36 +1300, Thomas Munro <thomas.munro@gmail.com> wrote in
> 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.
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