From 26f9e45c45bad2aa63e00008ed0470f017da4203 Mon Sep 17 00:00:00 2001 From: Robert Haas Date: Wed, 10 Jul 2024 16:56:14 -0400 Subject: [PATCH v1] Fix WAL summarization across abrupt timeline switch. The old code believed that it was not possible to switch timelines without first replaying all of the WAL from the old timeline, but that turns out to be false, as demonstrated by an example from Fujii Masao. As a result, it assumed that summarization would always continue from the LSN where summarization previously ended. But in fact, when a timeline switch occurs without replaying all the WAL from the previous timeline, we can need to back up to an earlier LSN. Adjust accordingly. --- src/backend/postmaster/walsummarizer.c | 32 +++++++++++++++----------- 1 file changed, 19 insertions(+), 13 deletions(-) diff --git a/src/backend/postmaster/walsummarizer.c b/src/backend/postmaster/walsummarizer.c index 55dc2ea8f5..da6f884d0c 100644 --- a/src/backend/postmaster/walsummarizer.c +++ b/src/backend/postmaster/walsummarizer.c @@ -387,13 +387,27 @@ WalSummarizerMain(char *startup_data, size_t startup_data_len) /* * If we've reached the switch LSN, we can't summarize anything else - * on this timeline. Switch to the next timeline and go around again. + * on this timeline. Switch to the next timeline and go around again, + * backing up to the exact switch point if we passed it. */ if (!XLogRecPtrIsInvalid(switch_lsn) && current_lsn >= switch_lsn) { + /* Restart summarization from switch point. */ current_tli = switch_tli; + current_lsn = switch_lsn; + + /* Next timeline and switch point, if any, not yet known. */ switch_lsn = InvalidXLogRecPtr; switch_tli = 0; + + /* Update (really, rewind, if needed) state in shared memory. */ + LWLockAcquire(WALSummarizerLock, LW_EXCLUSIVE); + WalSummarizerCtl->summarized_lsn = current_lsn; + WalSummarizerCtl->summarized_tli = current_tli; + WalSummarizerCtl->lsn_is_exact = true; + WalSummarizerCtl->pending_lsn = current_lsn; + LWLockRelease(WALSummarizerLock); + continue; } @@ -414,7 +428,6 @@ WalSummarizerMain(char *startup_data, size_t startup_data_len) /* Update state in shared memory. */ LWLockAcquire(WALSummarizerLock, LW_EXCLUSIVE); - Assert(WalSummarizerCtl->pending_lsn <= end_of_summary_lsn); WalSummarizerCtl->summarized_lsn = end_of_summary_lsn; WalSummarizerCtl->summarized_tli = current_tli; WalSummarizerCtl->lsn_is_exact = true; @@ -1026,7 +1039,6 @@ SummarizeWAL(TimeLineID tli, XLogRecPtr start_lsn, bool exact, /* Also update shared memory. */ LWLockAcquire(WALSummarizerLock, LW_EXCLUSIVE); - Assert(summary_end_lsn >= WalSummarizerCtl->pending_lsn); Assert(summary_end_lsn >= WalSummarizerCtl->summarized_lsn); WalSummarizerCtl->pending_lsn = summary_end_lsn; LWLockRelease(WALSummarizerLock); @@ -1369,17 +1381,11 @@ summarizer_read_local_xlog_page(XLogReaderState *state, * Allow reads up to exactly the switch point. * * It's possible that this will cause read_upto to move - * backwards, because walreceiver might have read a - * partial record and flushed it to disk, and we'd view - * that data as safe to read. However, the - * XLOG_END_OF_RECOVERY record will be written at the end - * of the last complete WAL record, not at the end of the - * WAL that we've flushed to disk. - * - * So switchpoint < private->read_upto is possible here, - * but switchpoint < state->EndRecPtr should not be. + * backwards, because we might have been promoted before + * reaching the end of the previous timeline. In that case, + * the next loop iteration will likely conclude that we've + * reached end of WAL. */ - Assert(switchpoint >= state->EndRecPtr); private_data->read_upto = switchpoint; /* Debugging output. */ -- 2.39.3 (Apple Git-145)