On Thu, Jul 16, 2026 at 2:05 AM Andrey Borodin <[email protected]> wrote: > Of course I'd like that fix committed too :) But that's not why I'm raising > it here. > > +# The reason for the problem is that when a new primary is promoted, the > +# partial file that ends the old timeline is renamed, giving it a ".partial" > +# suffix, and is not archived. That's not a problem for recovery, because > +# the bytes that appear at the start of that segment will be copied into the > +# first segment on the new timeline, and recovery will read them from there > +# and work just fine. > > That only holds when the new timeline's segment is already available. If it > isn't, > XLogFileReadAnyTLI() falls back to the ancestor's segment and, past the > switch point, > hands recovery the old timeline's divergent WAL. It's the mirror, on the > recovery > side, of what your patch fixes for the summarizer. > > I'm not asking you to fix XLogFileReadAnyTLI() here. I just don't think the > new > comment should claim recovery is unaffected.
In the scenario tested by this test case, recovery works fine. Without the patch, node3 follows the timeline switch from TLI 1 to TLI 2 and continues recovery thereafter without a problem. Only WAL summarization gets stuck. Maybe I need to go read your thread to figure out why you think these are the same problem, but based on what the test case does, I feel like they are different problems. -- Robert Haas EDB: http://www.enterprisedb.com
