Hi Chao, Manu,
Thanks both , that's a good correction. I didn't realize the summarizer backfills from the oldest WAL still on disk, so "summarization was not enabled" isn't really the trigger; it's WAL being recycled before summarization catches up. Dropping the conditional causes entirely also sidesteps the wal_level=minimal case not fitting them, as Manu pointed out.
v2 attached, using Chao's wording:
HINT: Consider taking a new full backup to use as the basis for future incremental backups.
Re-verified the summaries-removed path on master with the new wording. Manu, thanks also for independently confirming it on wal_level=minimal and that 007 still passes saves me chasing that path myself.
Regards,
Sai Pranav
Hi Sai,
I tried the patch on master (v1 applies cleanly, and 007 still passes
3/3) and reproduced the error on several paths, including the
wal_level=minimal case via 007. The hint shows up in all of them.
> Would a shorter "Take a new full backup." be preferable?
I think there is a case for it. On the minimal path the hint still
fires, but its two causes do not really fit: summarize_wal is off there
only because minimal requires it -- the actual reason is that the
summarizer reaches that WAL and skips it on purpose (fast_forward) --
and nothing was removed. And even in the main case the first cause is
more a symptom than the condition: with the WAL still on disk, enabling
summarize_wal after the full backup does not error, since the summarizer
backfills from the oldest WAL present; it only fails once that WAL has
been recycled before summarization caught up.
So the remedy-only form you suggested reads correctly in all of them.
If you would rather keep naming the minimal case, there is existing
wording to mirror at xlog.c:6037:
Use a backup taken after setting "wal_level" to higher than "minimal".
Happy to share the repro script if it helps.
Regards,
Manu
