On Wed, May 6, 2015 at 6:45 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> To be honest, now that you've pointed out that the fraction of the
> multixact members space that is in use will always be larger,
> generally much larger, than the fraction of the offset space that is
> in use, I've kind of lost all enthusiasm for making the
> safe_member_count stuff dependent on
> autovacuum_multixact_freeze_max_age. I'm inclined to go back to 25%,
> the way you had it before.
>
> We could think about adding a new GUC in master, but I'm actually
> leaning toward the view that we should just hard-code 25% for now and
> consider revising it later if that proves inadequate.
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.
Some residual concerns:
1. Should we be installing one or more GUCs to control this behavior?
I've gone back to hard-coding things so that at 25% we start
triggering autovacuum and by 75% we zero out the freeze ages, because
the logic you proposed in your last version looks insanely complicated
to me. (I do realize that I suggested the approach, but that was
before I realized the full complexity of the problem.) I now think
that if we want to make this tunable, we need to create and expose
GUCs for it. I'm hoping we can get by without that, but I'm not sure.
2. Doesn't the code that sets MultiXactState->multiVacLimit also need
to use what I'm now calling MultiXactMemberFreezeThreshold() - or some
similar logic? Otherwise, a user with autovacuum=off won't get
emergency autovacuums for member exhaustion, even though they will get
them for offset exhaustion.
Despite those concerns I think we're headed in the right direction here.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
