Re: Re: BUG #12990: Missing pg_multixact/members files (appears to have wrapped, then truncated)

So I might have understood an earlier description of the proposed
solution all wrong, or this patch was designed without consideration to
that description.  What I thought would happen is that all freeze ages
would get multiplied by some factor <= 1, depending on the space used up
by members.  If members space usage is low enough, factor would remain
at 1 so things would behave as today.  If members space usage is larger
than X, the factor decreases smoothly and this makes freeze_min_age and
freeze_max_age decrease smoothly as well, for all vacuums equally.

For instance, we could choose a method to compute X based on considering
that a full 2^32 storage area for members is enough to store one
vacuum_multixact_freeze_table_age cycle of multixacts.  The default
value of this param is 150 million, and 2^32/150000000 = 28; so if your
average multixact size = 38, you would set the multiplier at 0.736 and
your effective freeze_table_age would become 110 million and effective
freeze_min_age would become 3.68 million.


As a secondary point, I find variable-names-as-documentation bad
practice.  Please don't use a long name such as
max_multixact_age_to_avoid_member_wrap; code becomes unwieldy.  A short
name such as safe_mxact_age preceded by a comment /* this variable is
the max that avoids member wrap */ seems more palatable; side-by-side
merges and all that!  I don't think long function names are as
problematic (though the name of your new function is still a bit too
long).

Please note that 9.4 and earlier do not have ExecVacuum; the
determination of freeze ages is done partly in gram.y (yuck).  Not sure
what will the patch look like in those branches.

--
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services