On Fri, May 8, 2015 at 8:32 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> 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 is definitely tidier.
> This will need some testing to make sure it still works; I haven't done that.
I tested it with autovacuum on, and it automatically vacuumed after
25% of member space was used.
I tested it with autovacuum off, and I ran a VACUUM manually every few
minutes and checked that it didn't advance my database's datminmxid,
until after 25% of member space was used, after which a full scan was
triggered and datminmxid moved. As expected, that didn't advance the
cluster-wide oldest multixact, because for that you'd need to vacuum
ALL databases including non-connectable ones. (This patch doesn't
update the forced-autovacuum-even-if-autovacuum-is-off feature to
handle member space wraparound in GetNextMultiXactId, which is coming
in a separate patch[1].)
So it works as expected.
[1] http://www.postgresql.org/message-id/CA+TgmobbaQpE6sNqT30+rz4UMH5aPraq20gko5xd2ZGajz1-Jg@mail.gmail.com
--
Thomas Munro
http://www.enterprisedb.com