Fix multixact backwards-compatibility with CHECKPOINT race condition If a CHECKPOINT record with nextMulti N is written to the WAL before the CREATE_ID record for N, and N happens to be the first multixid on an offset page, the backwards compatibility logic to tolerate WAL generated by older minor versions (before commit 789d65364c) failed to compensate for the missing XLOG_MULTIXACT_ZERO_OFF_PAGE record. In that case, the latest_page_number was initialized at the start of WAL replay to the page for nextMulti from the CHECKPOINT record, even if we had not seen the CREATE_ID record for that multixid yet, which fooled the backwards compatibility logic to think that the page was already initialized.
To fix, track the last XLOG_MULTIXACT_ZERO_OFF_PAGE that we've seen separately from latest_page_number. If we haven't seen any XLOG_MULTIXACT_ZERO_OFF_PAGE records yet, use SimpleLruDoesPhysicalPageExist() to check if the page needs to be initialized. Reported-by: duankunren.dkr <[email protected]> Analyzed-by: duankunren.dkr <[email protected]> Reviewed-by: Andrey Borodin <[email protected]> Reviewed-by: Kirill Reshke <[email protected]> Discussion: https://www.postgresql.org/message-id/c4ef1737-8cba-458e-b6fd-4e2d6011e985.duankunren....@alibaba-inc.com Backpatch-through: 14-18 Branch ------ REL_16_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/77dff5d937b192b85c55bce822e7413ff7dda6eb Modified Files -------------- src/backend/access/transam/multixact.c | 83 +++++++++++++++++++++++++++------- src/include/access/slru.h | 4 +- 2 files changed, 68 insertions(+), 19 deletions(-)
