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!
Best regards On Tue, 23 Apr 2024 at 17:37, Heikki Linnakangas <hlinn...@iki.fi> wrote: > On 23/04/2024 11:23, Maxim Orlov wrote: > > PROPOSAL > > Make multixact offsets 64 bit. > > +1, this is a good next step and useful regardless of 64-bit XIDs. > > > @@ -156,7 +148,7 @@ > > ((uint32) ((0xFFFFFFFF % MULTIXACT_MEMBERS_PER_PAGE) + 1)) > > > > /* page in which a member is to be found */ > > -#define MXOffsetToMemberPage(xid) ((xid) / (TransactionId) > MULTIXACT_MEMBERS_PER_PAGE) > > +#define MXOffsetToMemberPage(xid) ((xid) / (MultiXactOffset) > MULTIXACT_MEMBERS_PER_PAGE) > > #define MXOffsetToMemberSegment(xid) (MXOffsetToMemberPage(xid) / > SLRU_PAGES_PER_SEGMENT) > > > > /* Location (byte offset within page) of flag word for a given member */ > > 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. > > -- > Heikki Linnakangas > Neon (https://neon.tech) > > > >
