On 2025-Dec-05, Andrey Borodin wrote:
> I'm on-call for the rest of this week, but a bit later I can produce
> fast tests for all kinds of wraparounds :)
I suspect that would be valuable.
> But as you said, hopefully soon there won't be wraparounds, and,
> what's more important, offsets\members space exhaustion.
Hmm. We can easily enlarge the offset size to 64 bits, which eliminates
the problem of member wraparound and space exhaustion. However,
enlarging multixact size itself would require enlarging the size of the
t_xmax field in heap tuples, and as far as I know, that's not in the
works. I mean, even with the patches to increase xid to 64 bits[1], I
understand that t_xmax continues to be 32 bits. This means that
multixact offset wraparound is still an issue that we need to pay
attention to.
[1] https://postgr.es/m/CACG=ezYeSygeb68tJVej9Qgji6k78V2reSqzh1_Y4P5GxCAGsw@mail.gmail.com
As far as I understand from that patch, XIDs as stored in t_xmax are
still 32 bits, and are made 64 bits by addition of the pd_xid_base
value. This technique can be used for standard XIDs; but multixacts,
having their own cycle from XIDs, cannot be offset by the same counter.
It would require a separate pd_multixact_base value to be maintained for
each page.
--
Álvaro Herrera 48°01'N 7°57'E — https://www.EnterpriseDB.com/
"Escucha y olvidarás; ve y recordarás; haz y entenderás" (Confucio)
