Hi Andrey, Thank you for the new patch.
I applied v3 to current master. The xlogrecovery.c change applies cleanly, but the meson.build conflicts with 't/056_standby_snapshot_export.pl' (added by 79b101486c1, Aug 26) where v3 inserts after 055, and 056_timeline_switch_archive_divergence.pl duplicates that number. Renumbering the tests to 057/058 and refreshing the meson should fix this. One thing about the new DEBUG1: the break is reached whenever the newest eligible timeline's segment isn't available, which includes the ordinary case of an archive-based standby (restore_command, no streaming) waiting for the next segment to appear. With a single timeline, readTimeLineHistory() returns one entry whose begin is InvalidXLogRecPtr, so the beginseg check is skipped, both reads fail, and we log "not searching older timelines" even though there were no older timelines to search, repeated every wal_retrieve_retry_interval. Could it be gated on there actually being an older timeline to abandon, i.e. only when the eligible entry isn't the last in expectedTLEs? That would confine it to the case it describes, and would then be rare enough to justify LOG, which is where it'd actually help an operator facing a stall. A small nit: XLogFileName() writes a filename into the local called "path", which is then reused after the loop by XLogFilePath() for an actual path. XLogFileRead() just above keeps a separate xlogfname[MAXFNAMELEN] for exactly this, matching that would read better. Feel free to drop this, just a suggestion. Overall v3 patch looks good and is heading in the right direction. Regards, Surya Poondla
