Re: Be strict when request to flush past end of WAL in WaitXLogInsertionsToFinish

> Just curious, how did the bogus LSN end up in asyncXactLSN in
> production when you hit the issue?

Honestly, we still don't know, but the value itself is telling.

The production request was exactly segment boundary + 0x28, i.e.
SizeOfXLogLongPHD past a segment start. That is precisely what the
current insert position looks like right after a segment switch,
before any record has been written into the new segment. So it does
not look like random corruption; it looks like something captured the
insert position at that moment and handed it to XLogSetAsyncXactLSN().
That is also how the TAP test's injector reproduces the incident
byte-for-byte.

I went looking for an in-core path that could do this naturally on the
affected version and came up empty: fault-free segment switches
(~100 runs), async commits, LogStandbySnapshot() calls, and top-level
aborts never produced the "past end of generated WAL" warning in my
testing. The affected installation does load third-party preload
libraries; auditing those for WAL-related symbol use is on my list but
has not been done yet, so I cannot rule the source in or out.

Either way, I think the fix stands on its own: whatever plants the
value, WaitXLogInsertionsToFinish() already detects and clamps it, and
XLogBackgroundFlush() discarding that clamp is what turns one bad
request into the standby's prev-link retry loop.

Regards,
Paul Kim