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.
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
