Re: Rework the way multixact truncations work

Hi,

On October 29, 2015 7:59:03 AM GMT+01:00, Noah Misch <noah(at)leadboat(dot)com> wrote:
>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.

Great!

> I propose to save some time by writing a patch series
>eliminating
>them, which you could hopefully review. Does that sound good?

Yes, it does.

Andres

---
Please excuse brevity and formatting - I am writing this on my mobile phone.