Moving MultiXactOffset to 64 Bits in Postgres

Introduction One morning, while going through the latest batch of Postgres commits, I saw this : commit bd8d9c9bdfa0c2168bb37edca6fa88168cacbbaa Author: Heikki Linnakangas heikki.linnakangas@iki.fi Date: Tue Dec 9 13:53:03 2025 +0200 Widen MultiXactOffset to 64 bits This eliminates MultiXactOffset wraparound and the 2^32 limit on the total number of multixid members. Multixids are still limited to 2^31, but this is a nice improvement because 'members' can grow much faster than the number of multixids. On such systems, you can now run longer before hitting hard limits or triggering anti-wraparound vacuums. Just like that, quietly and almost routinely, Postgres moved past one of its annoying limits: the cap on the number of transactions in a multitransaction is now history. Formally, yes, it is now limited by an 8-byte unsigned integer, but that number is so massive that I can’t imagine it being exhausted anytime in the foreseeable future. When you spend years working on something and it finally gets done, it’s hard to believe it’s really over. There was always a small chance the community could still roll the commit back. Now that almost three months have passed (and the commit seems to have settled in), I want to share my thoughts as a direct participant in these events and the patch author. Three juggling brothers In Postgres, there are three bottlenecks tied to 32-bit counters: transaction identifiers, also known as xid or “xids”; multitransaction identifiers, also known as mxid; multitransaction offsets. Users rarely notice this one, but under the wrong conditions, it can become quite nasty. More on that later. It’s worth noting that each of these counters can “wrap around,” meaning they handle overflow normally, and this does not crash the database or cause data loss. Depending on your workload and database size, you might not even notice that, say, after 4 billion, the transaction counter has become 1073. Any of these counters can become a problem, or not. Each