Hi Andres, I hit this issue today because I am trying to reproduce a buffer pin conflict workload.
I tried your idea and It gives too much grace when the standby is really behind. I use max_standby_streaming_delay = 5s and paused replay for 7 seconds and resumed it. It still waited 5 more seconds before send signal. The attached patch uses the time of the previous flushedUpto read instead of now. The WAL at RecPtr was not flushed yet at that read, so it arrived after it. A standby that keeps up gets a recent time. A standby that is behind cancels at once. Thanks, Shihao
0001-Fix-stale-XLogReceiptTime-on-a-standby-that-keeps.patch
Description: Binary data
nocfbot-repro.patch
Description: Binary data
