Re: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline - Mailing list pgsql-hackers

From surya poondla
Subject Re: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline
Date
Msg-id CAOVWO5rp=xu_VUNDXzXXCc7bih2H8_NGct5U10-9pafef=SxMw@mail.gmail.com
Whole thread
In response to Re: Fix XLogFileReadAnyTLI silently applying divergent WAL from wrong timeline  (Andrey Borodin <x4mmm@yandex-team.ru>)
Responses Re: Race conditions during parallel worker (unclean) exit
List pgsql-hackers
Hi Andrey,

Thanks for v4. I applied it to the current master (86f7c82cf10) it applies
and builds cleanly. The xlogfname split and the 057/058 renumbering both look right.

Fair enough on keeping it at DEBUG1, announcing a declined action at LOG does sit oddly.

What I'd still raise is narrower. Where a parent timeline exists the message is accurate. But in a single-timeline case, where there is no parent to fall back to, so the message describes something that cannot happen and it still fires on every retry. On an idle archive-only standby with no history files I measured about five a second at wal_retrieve_retry_interval = 200ms, all of them reading "not searching older timelines ... The whole segment must be read from timeline 1".

Gating it on there actually being an older timeline to abandon i.e. only when the eligible entry isn't the last in expectedTLEs would confine the message to the case where it's true, and the tests would still get their hook since they exercise the multi-timeline case.

Not a blocker from my side. v4 looks good to me and I think it's ready for a committer.

Regards,
Surya Poondla

pgsql-hackers by date:

Previous
From: Bharath Rupireddy
Date:
Subject: Re: Support for 8-byte TOAST values, round two
Next
From: Richard Guo
Date:
Subject: Re: Assert failure in try_nestloop_path()