Fix tracking of the nextMulti in the pageserver's copy of CheckPoint

[knizhnik]

Whenever we see an XLOG_MULTIXACT_CREATE_ID WAL record, we need to
update the nextMulti and NextMultiOffset fields in the pageserver's
copy of the CheckPoint struct, to cover the new multi-XID. In
PostgreSQL, this is done by updating an in-memory struct during WAL
replay, but because in Neon you can start a compute node at any LSN,
we need to have an up-to-date value pre-calculated in the pageserver
at all times. We do the same for nextXid.

However, we had a bug in WAL ingestion code that does that: the
multi-XIDs will wrap around at 2^32, just like XIDs, so we need to do
the comparisons in a wraparound-aware fashion.

Fix that, and add tests.

Fixes issue #6520

Co-authored-by: Konstantin Knizhnik knizhnik@neon.tech

[github-actions]

2946 tests run: 2829 passed, 0 failed, 117 skipped (full report)

---

Flaky tests (2)

Postgres 15

• test_wal_restore_initdb: debug
• test_wal_restore: debug

Code coverage* (full report)

• functions: 32.7% (6914 of 21129 functions)
• lines: 50.1% (54205 of 108189 lines)

* collected from Rust tests only

---

_{The comment gets automatically updated with the latest test results
30027d9 at 2024-06-30T23:39:49.563Z :recycle:}

[hlinnaka]

Please create a test. Something similar to the test_import_at_2bil test should do the trick.

[hlinnaka]

I did some work on this to get this to completion:

• I refactored the code changes, by creating a new update_next_multixid() function similar to update_next_xid(). It's a lot simpler than update_next_xid(), so this is perhaps overkill, but it makes it also possible to write a unit test. That might also seem like overkill, but this wraparound behavior is very easy to get subtly wrong, so better safe than sorry. It's also nice that it's more symmetrical with update_next_xid().
• I created a unit test for the update_next_multixid() function
• I changed the code to not skip over multi-xid 0. Per discussion, Postgres also doesn't skip over it, which is admittedly weird, but I'd prefer to stick close to Postgres unless there's a reason to do something different.
• I created a python test too. It uses pg_resetwal to get within spitting distance of multixid/offset wraparound, and then performs some real updates to get over the line

[arssher]

The CI v14 failure is interesting; TruncateMultiXact does enter critical section, and CompactCheckpointerRequestQueue does indeed pallocs. Not related to neon on the first glance.

[hlinnaka]

The CI v14 failure is interesting; TruncateMultiXact does enter critical section, and CompactCheckpointerRequestQueue does indeed pallocs. Not related to neon on the first glance.

Yep, that's a PostgreSQL bug. I posted that to pgsql-hackers: https://www.postgresql.org/message-id/ccc66933-31c1-4f6a-bf4b-45fef0d4f22e%40iki.fi