On 5/8/15 1:15 PM, Robert Haas wrote:
> I somehow did not realize until very recently that we
> actually use two SLRUs to keep track of multixacts: one for the
> multixacts themselves (pg_multixacts/offsets) and one for the members
> (pg_multixacts/members). Confusingly, members are sometimes called
> offsets, and offsets are sometimes called IDs, or multixacts.
FWIW, since I had to re-read this bit... * We use two SLRU areas, one for storing the offsets at which the data *
startsfor each MultiXactId in the other one. This trick allows us to * store variable length arrays of
TransactionIds.
Another way this could be 'fixed' would be to bump MultiXactOffset (but
NOT MultiXactId) to uint64. That would increase the number of total
members we could keep by a factor of 2^32. At that point wraparound
wouldn't even be possible, because you can't have more than 2^31 members
in an MXID (and there can only be 2^31 MXIDs). It may not be a trivial
change through, because SLRUs are currently capped at 2^32 pages.
This probably isn't a good long-term solution, but it would eliminate
the risk of really frequent freeze vacuums. It sounds like Josh at least
knows some people that could cause big problems for.
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
