Re: Rework the way multixact truncations work

On Tue, Oct 27, 2015 at 03:44:10PM +0100, Andres Freund wrote:
> On 2015-10-24 22:07:00 -0400, Noah Misch wrote:
> > On Tue, Sep 22, 2015 at 07:57:27PM +0200, Andres Freund wrote:
> > > On 2015-09-22 13:38:58 -0400, Robert Haas wrote:
> > > > - If SlruDeleteSegment fails in unlink(), shouldn't we at the very
> > > > least log a message? If that file is still there when we loop back
> > > > around, it's going to cause a failure, I think.
> > >
> > > The existing unlink() call doesn't, that's the only reason I didn't add
> > > a message there. I'm fine with adding a (LOG or WARNING?) message.
>
> Note that I didn't add the warning after all, as it'd be too noisy
> during repeated replay, as all the files would already be gone. We could
> only emit it when the error is not ENOFILE, if people prefer that.
>
>
> > Unlinking old pg_clog files is strictly an optimization. If you were to
> > comment out every unlink() call in slru.c, the only ill effect on CLOG is the
> > waste of disk space. Is the same true of MultiXact?
>
> Well, multixacts are a lot larger than the other SLRUs, I think that
> makes some sort of difference.

That helps; thanks. Your design seems good. I've located only insipid
defects. I propose to save some time by writing a patch series eliminating
them, which you could hopefully review. Does that sound good?