> 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
