walsummarizer: Guard against WAL files whose tail ends are not valid. SummarizeWAL documents that maximum_lsn should be passed as "the switch point when reading a historic timeline, or the most-recently-measured end of WAL when reading the current timeline." But the caller always passed the most recently measured end-of-WAL even when reading from a historic timeline, due to an oversight on my part. Fix that.
As far as I can determine, for this to become an issue in practice, it's necessary to have a corrupted WAL file in the archive. SummarizeWAL checks that every record it processes both starts and ends before switch_lsn; so if all the WAL files in the archive are valid, SummarizeWAL will still discover where it should stop summarizing and do the right thing. However, if there's a corrupted file in the WAL archive, and if it is also the case that the end of the current timeline has advanced past the switch point, then the incorrect maximum_lsn value can result in trying to read an invalid record and erroring out, which leads repeatedly retrying and failing with an error every time. One way this could occur is if a new primary is promoted and creates a .partial file, and the user manually renames that file to remove the suffix, and it is then archived. In that situation, the tail end of the file need not be valid WAL, and that could lead to a stuck WAL summarizer. Reported-by: Fabrice Chapuis <[email protected]> Analyzed-by: Thom Brown <[email protected]> (using claude) Discussion: http://postgr.es/m/caa5-nlddvgmkn6z-gahghg5t7qwegv4yoho7xvojbed00cg...@mail.gmail.com Backpatch-through: 17 Branch ------ master Details ------- https://git.postgresql.org/pg/commitdiff/8767a10cb8c5d08b924f40c8fc1f2a1e5fb8c55e Modified Files -------------- src/backend/postmaster/walsummarizer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
