On Wed, May 6, 2015 at 9:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> So here's a new patch, based on your latest version, which looks
> reasonably committable to me. I made a lot of revisions to the
> comments. I changed some variable and function names, too. I also
> reworked the function that determines the accelerated freeze threshold
> because I was afraid that the integer return value might not be large
> enough to accommodate the uint32 result of the derating calculation,
> which would then turn negative. The new logic is also, I believe,
> less vulnerable to floating-point roundoff dangers. And I tightened
> up the documentation.
Here's a new revision of this patch. When I looked into back-patching
this, it conflicted in ExecVacuum(). And the more I thought about
that, the less I liked it, because I think ExecVacuum() is really
intended to translate from the parse tree representation to whatever
internal representation we're going to pass to vacuum, NOT to make
policy decisions. So in the attached version, what I did instead is
modify vacuum_set_xid_limits() to call
MultiXactMemberFreezeThreshold() itself instead of trying to pass that
value down via the vacuum options. It seems to me that this greatly
reduces the chances of inconsistency between member-wrap vacuums and
offset-wrap vacuums. The code seems more elegant, too:
MultiXactMemberFreezeThreshold() now returns
autovacuum_multixact_freeze_max_age rather than -1 when no special
handling is needed to prevent member wraparound, and all of the
callers now find this convention convenient. As a bonus, it now
back-patches to 9.4 without conflicts. There are some conflicts on
9.3 but they don't look bad.
This will need some testing to make sure it still works; I haven't done that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company