Thomas Munro wrote:
> FWIW, in some future release, I think we should consider getting a
> bigger multixact member address space that wraps around at 2^48 or
> 2^64 instead of 2^32, so that we can sidestep the whole business and
> go back to having just xid and mxid wraparounds to worry about.
> pg_multixact/offsets would be 50% or 100% bigger (an extra byte or two
> per multixact), but it's not very big. pg_multiact/members would be
> no bigger for any workload that currently works without hitting the
> wraparound error, but could grow bigger if needed.
Not sure that enlarging the addressable area to 48/64 bits is feasible,
TBH. We already have many complaints that multixacts take too much disk
space; we don't want to make that 2^32 times worse, not even 2^16 times
worse. I don't understand why you say it'd become 1 byte bigger per
multixact; it would have to be 4 more bytes (2^64) or 2 more bytes
(2^48), no? If you have 150 million multixacts (the default freeze
table age) that would mean about 300 or 600 MB of additional disk space,
which is not insignificant: with the current system, in an database with
normal multixact usage of 4 members per multixact, members/ would use
about 2.8 GB, so 600 additional MB in offsets/ is large enough growth to
raise some more complaints.
(The 2^48 suggestion might be a tad more difficult to implement, note,
becase a lot of stuff relies on unsigned integer wraparound addition,
and I'm not sure we can have that with a 2^48 counter. Maybe we could
figure how to make it work, but is it worth the bother?)
--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services