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

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