Re: multixacts woes

On Sun, May 10, 2015 at 1:40 PM, Noah Misch <noah@leadboat.com> wrote:
> I don't know whether this deserves prompt remediation, but if it does, I would
> look no further than the hard-coded 25% figure.  We permit users to operate
> close to XID wraparound design limits.  GUC maximums force an anti-wraparound
> vacuum at no later than 93.1% of design capacity.  XID assignment warns at
> 99.5%, then stops at 99.95%.  PostgreSQL mandates a larger cushion for
> pg_multixact/offsets, with anti-wraparound VACUUM by 46.6% and a stop at
> 50.0%.  Commit 53bb309d2d5a9432d2602c93ed18e58bd2924e15 introduced the
> bulkiest mandatory cushion yet, an anti-wraparound vacuum when
> pg_multixact/members is just 25% full.

That's certainly one possible approach.  I had discounted it because
you can't really get more than a small multiple out of it, but getting
2-3x more room might indeed be enough to help some people quite a bit.
Just raising the threshold from 25% to say 40% would buy back a
healthy amount.

Or, as you suggest, we could just add a GUC.

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