agora inbox for pgsql-committers@postgresql.orghelp / color / mirror / Atom feed
pgsql: walsummarizer: Guard against WAL files whose tail ends are not v 4+ messages / 1 participants [nested] [flat]
* pgsql: walsummarizer: Guard against WAL files whose tail ends are not v @ 2026-07-22 13:09 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Robert Haas @ 2026-07-22 13:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <fabrice636861@gmail.com> Analyzed-by: Thom Brown <thom@linux.com> (using claude) Discussion: http://postgr.es/m/CAA5-nLDdvGMkN6Z-GaHGHG5T7QWEgv4YoHO7XvOJbeD00cghNg@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(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: walsummarizer: Guard against WAL files whose tail ends are not v @ 2026-07-22 13:09 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Robert Haas @ 2026-07-22 13:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <fabrice636861@gmail.com> Analyzed-by: Thom Brown <thom@linux.com> (using claude) Discussion: http://postgr.es/m/CAA5-nLDdvGMkN6Z-GaHGHG5T7QWEgv4YoHO7XvOJbeD00cghNg@mail.gmail.com Backpatch-through: 17 Branch ------ REL_19_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/bdcea66f0f3b2f16c51d6c95bb9d0bb317fdfd99 Modified Files -------------- src/backend/postmaster/walsummarizer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: walsummarizer: Guard against WAL files whose tail ends are not v @ 2026-07-22 13:09 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Robert Haas @ 2026-07-22 13:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <fabrice636861@gmail.com> Analyzed-by: Thom Brown <thom@linux.com> (using claude) Discussion: http://postgr.es/m/CAA5-nLDdvGMkN6Z-GaHGHG5T7QWEgv4YoHO7XvOJbeD00cghNg@mail.gmail.com Backpatch-through: 17 Branch ------ REL_18_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/1d299d6abfcdcd9400dd1e14b4213a9f39e41691 Modified Files -------------- src/backend/postmaster/walsummarizer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
* pgsql: walsummarizer: Guard against WAL files whose tail ends are not v @ 2026-07-22 13:09 Robert Haas <rhaas@postgresql.org> 0 siblings, 0 replies; 4+ messages in thread From: Robert Haas @ 2026-07-22 13:09 UTC (permalink / raw) To: pgsql-committers@lists.postgresql.org 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 <fabrice636861@gmail.com> Analyzed-by: Thom Brown <thom@linux.com> (using claude) Discussion: http://postgr.es/m/CAA5-nLDdvGMkN6Z-GaHGHG5T7QWEgv4YoHO7XvOJbeD00cghNg@mail.gmail.com Backpatch-through: 17 Branch ------ REL_17_STABLE Details ------- https://git.postgresql.org/pg/commitdiff/d28cdf46e6a4d55cd324b8db6148f6ebc552f52e Modified Files -------------- src/backend/postmaster/walsummarizer.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) ^ permalink raw reply [nested|flat] 4+ messages in thread
end of thread, other threads:[~2026-07-22 13:09 UTC | newest] Thread overview: 4+ messages (download: mbox mbox.gz follow: Atom feed) -- links below jump to the message on this page -- 2026-07-22 13:09 pgsql: walsummarizer: Guard against WAL files whose tail ends are not v Robert Haas <rhaas@postgresql.org> 2026-07-22 13:09 pgsql: walsummarizer: Guard against WAL files whose tail ends are not v Robert Haas <rhaas@postgresql.org> 2026-07-22 13:09 pgsql: walsummarizer: Guard against WAL files whose tail ends are not v Robert Haas <rhaas@postgresql.org> 2026-07-22 13:09 pgsql: walsummarizer: Guard against WAL files whose tail ends are not v Robert Haas <rhaas@postgresql.org>
This inbox is served by agora; see mirroring instructions for how to clone and mirror all data and code used for this inbox