Re: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline

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