On Sun, May 10, 2015 at 1:40 PM, Noah Misch <n...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
