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?
I think I see why I was seeing this and nobody else was -- I was
testing the cleanup on an otherwise quiescent cluster. It seems
that no amount of VACUUM and CHECKPOINT will clean up the members
subdirectory in the absence of processes adding more members. But
after performing the VACUUMs and CHECKPOINT if I start the test
program to add more multi-transactions with lots of members, *then*
the members subdirectory gets cleaned up. That seems confusing and
a bit annoying, but is otherwise benign. I would put "allow VACUUM
followed by CHECKPOINT to delete unneeded files from the members
subdirectory" on the "nice to have" list, but would not want to
delay a fix for the corruption issues for it.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company