Update pageserver to store multixacts per region #51
Conversation
| fn mx_offset_to_member_page(xid: u32, region: u32) -> u32 { | ||
| ((xid / pg_constants::MULTIXACT_MEMBERS_PER_PAGE as u32) * pg_constants::MAX_REGIONS as u32) + region | ||
| } | ||
|
|
||
| pub fn mx_offset_to_member_segment(xid: u32) -> i32 { | ||
| (mx_offset_to_member_page(xid) / pg_constants::SLRU_PAGES_PER_SEGMENT) as i32 | ||
| pub fn mx_offset_to_member_segment(xid: u32, region: u32) -> i32 { | ||
| (mx_offset_to_member_page(xid, region) / pg_constants::SLRU_PAGES_PER_SEGMENT) as i32 | ||
| } |
There was a problem hiding this comment.
In postgres, there are also MultiXactIdToOffsetPage and MultiXactIdToOffsetSegment macros to locate a multixact id in the offset slru, are there equivalence in the pageserver or are they not used there??
There was a problem hiding this comment.
Oh I think I see it now. In walredo, they inline the formula in the code.
There was a problem hiding this comment.
Yes, just for reference, I had made the calls with the same logic here: https://github.com/umd-dslam/postgres/blob/201b091a2f8a5c96c81f8b8a8425ae5e534ed4cb/src/backend/access/transam/multixact.c#L112
There was a problem hiding this comment.
About the walredo -- I was unsure as well, but they have these expected_* variables that they check for segment and offset; maybe that's the reason for computing it without the macros.
This change ensures that the pageserver stores and server multixacts per region. The mechanism is similar to that used for CSNlog.