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?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
