Replay lag can build up naturally, even when recovery_min_apply_delay is not set, because WAL generation on master is concurrent and WAL replay on standby is performed by a single process.
Hao and I have incorporated the new GUC from Konstantin's patch and used it to start WAL receiver in the main replay loop, regardless of whether recover_min_apply_delay is set. Instead of going through each existing WAL record to determine the streaming start point, WAL received is changed to persist WAL segment number of a new WAL segment just before it is created. WAL streaming always begins from WAL segment boundary. The persistent segment number can be easily used to compute the start point, which is the beginning of that segment. We also have a TAP test to demonstrate the problem in two situations - (1) WAL receiver process dies due to replication connection getting disconnected and (2) standby goes through restart. The test uses recovery_min_apply_delay to delay the replay and expects new commits made after WAL receiver exit to not block. Asim
v2-0001-Test-that-replay-of-WAL-logs-on-standby-does-not-.patch
Description: Binary data
v2-0002-Start-WAL-receiver-before-startup-process-replays.patch
Description: Binary data
