This is really a bug fix. It didn't matter when TransactionId and
MultiXactOffset were both typedefs of uint32, but it was always wrong.
The argument name 'xid' is also misleading.
I think there are some more like that, MXOffsetToFlagsBitShift for example.
Yeah, I always thought so too. I believe, this is just a copy-paste. You mean, it is worth creating a separate CF
entry for these fixes?
BTW as a side note... I see lot's of casts to (unsigned long long), can't we just cast to MultiXactOffset?
Actually, first versions of the 64xid patch set have such a cast to types TransactionID, MultiXact and so on. But,
after some discussions, we are switched to unsigned long long cast. Unfortunately, I could not find an exact link
for that discussion. On the other hand, such a casting is already used throughout the code. So, just for the
sake of the consistency, I would like to stay with these casts.
Hi Maxim Orlov
Thank you so much for your tireless work on this. Increasing the WAL size by a few bytes should have very little impact with today's disk performance(Logical replication of this feature wal log is also increased a lot, logical replication is a milestone new feature, and the community has been improving the logical replication of functions),I believe removing troubled postgresql Transaction ID Wraparound was also a milestone new feature adding a few bytes is worth it!
I'm 100% agree. Maybe, I should return to this approach and find some benefits for having FXIDs in WAL.