On Mon, Jul 13, 2026 at 6:07 PM Thom Brown <[email protected]> wrote: > Ha, yes, this is certainly a clear example of the confidence AI puts > in its own conclusions not being indicative of reliability.
Yep. And it's an odd oversight, too, since apportioning blame between SummarizeWAL and its caller seems to be the whole deal here, and the comments are how you figure out whose fault it is (at least, if they say anything useful). > So really, this doesn't sound like this is solved, not that these > changes aren't still necessary. I assume it's likely that Fabrice ended up with a not-totally-valid WAL file in the archive after some series of manual steps and couldn't quite remember what had been done well enough to provide an exact reproducer. That seems like a completely reasonable thing to happen to somebody. Now it's also possible that there is some as-yet-unknown way for this to happen without manual fudging, but unless somebody can figure out what that is exactly, it's hard to say what we ought to do about it. > > I attach a patch. I don't think we need anything like the 0002 in your > > proposal from claude. The read horizon used by the WAL summarizer > > *has* to be valid; if we can't achieve that, we're doomed. > > Nick, you said that you saw something "similar" (suggesting that it's > not identical), but you didn't explain what that was. Is there > potentially a separate bug that needs reporting? See the "walsummarizer can get stuck when switching timelines" thread. That case occurs when there's a timeline switch and the file from the old timeline doesn't make it into the archive at all. This case occurs where there's a timeline switch and a corrupted file from the old timeline makes it into the archive. It's possible to reproduce that case without any manual steps; see the included test case on that thread. As I say, I can believe that there could be a way to reproduce this case without manual steps too, but I don't know what it is. -- Robert Haas EDB: http://www.enterprisedb.com
