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

On Tue, May 5, 2015 at 3:58 AM, Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> Ok, the new patch uses 25% as the safe threshold, and then scales
> multixact_freeze_table_age down from the current number of active
> multixacts (ie to select the minimum number of tables) progressively
> to 0 (to select all tables) when you reach 75% usage.

I definitely think that 25% is better than 50%.  But see below.

> Ok, so if you have autovacuum_freeze_max_age = 400 million multixacts
> before wraparound vacuum, which is ~10% of 2^32, we would interpret
> that to mean 400 million multixacts OR ~10% * some_constant of member
> space, in other worlds autovacuum_freeze_max_age * some_constant
> members, whichever comes first.  But what should some_constant be?

some_constant should be all the member space there is.  So we trigger
autovac if we've used more than ~10% of the offsets OR more than ~10%
of the members.  Why is autovacuum_multixact_freeze_max_age
configurable in the place?  It's configurable so that you can set it
low enough that wraparound scans complete and advance the minmxid
before you hit the wall, but high enough to avoid excessive scanning.
The only problem is that it only lets you configure the amount of
headroom you need for offsets, not members.  If you squint at what I'm
proposing the right way, it's essentially that that GUC should control
both of those things.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company