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
