On Fri, Apr 24, 2015 at 5:18 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Apr 21, 2015 at 5:16 PM, Kevin Grittner <kgrittn@ymail.com> wrote:
>> Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>>> Here's a patch. I have tested locally and it closes the issue
>>> for me. If those affected can confirm that it stops the file
>>> removal from happening, I'd appreciate it.
>>
>> Based on initial testing, it seems to stop file removal from
>> happening rather too well. Before applying the patch I ran a test
>> test that generated files 0000 to 1185D in the members directory.
>> Even setting vacuum_multixact_freeze_min_age and
>> vacuum_multixact_freeze_table_age very low, none of the members
>> files would go away with VACUUM (with and without FREEZE) followed
>> by CHECKPOINT. After applying the patch and starting with a fresh
>> initdb, with very low settings of the vacuum_multixact_* GUCs I get
>> the new error almost immediately, while the only file in the
>> members subdirectory is 0000 and it is 8kB in size.
>>
>> I think the calculations might be wrong, but I'm not sure what does
>> make sense.
>
> Can anyone else reproduce this?
Yes. This happens in a fresh initdb-ed database. We start out with
oldestOffset = 0, oldestOffsetStopLimit = 4294914944 (that's 0 -
safety margin), nextOffset = 0. Then the first attempt to generate a
new multixact ID fails, because
MultiXactOffsetPrecedes(oldestOffsetStopLimit, nextOffset + nmembers)
is true. I guess the patch works correctly when you start out with an
unpatched database server and generate more than 2.whatever billion
members, and then you restart with the patch, and then start adding
more members until MultiXactOffsetPrecedes(...) returns true and you
get the error.
That's why I proposed not using xid-like logic, and instead using a
type of three-way comparison that allows you to see when nextOffset
would 'cross' oldestOffsetStopLimit, instead of the two-way comparison
that considers half the number-space to be in the past and half in the
future, in my earlier message.
--
Thomas Munro
http://www.enterprisedb.com
