Re: multixacts woes

On Sun, May 10, 2015 at 09:17:58PM -0400, Robert Haas wrote:
> On Sun, May 10, 2015 at 1:40 PM, Noah Misch <noah(at)leadboat(dot)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.

Right. It's fair to assume that the new VACUUM burden would be discountable
at a 90+% threshold, because the installations that could possibly find it
expensive are precisely those experiencing corruption today. These reports
took eighteen months to appear, whereas some corruption originating in commit
0ac5ad5 saw reports within three months. Therefore, sites burning
pg_multixact/members proportionally faster than both pg_multixact/offsets and
XIDs must be unusual. Bottom line: if we do need to reduce VACUUM burden
caused by the commits you cited upthread, we almost certainly don't need more
than a 4x improvement.