Re: Unnecessary delay in streaming replication due to replay lag

> On 09-Aug-2020, at 2:11 PM, Michael Paquier <michael@paquier.xyz> wrote:
> 
> I have not really looked at the proposed patch, but it would be good
> to have some documentation.
> 

Ah, right.  The basic idea is to reuse the logic to allow read-only connections to also start WAL streaming.  The patch
borrowsa new GUC “wal_receiver_start_condition” introduced by another patch alluded to upthread.  It affects when to
startWAL receiver process on a standby.  By default, the GUC is set to “replay”, which means no change in current
behavior- WAL receiver is started only after replaying all WAL already available in pg_wal.  When set to “consistency”,
WALreceiver process is started earlier, as soon as consistent state is reached during WAL replay.
 

The LSN where to start streaming from is determined to be the LSN that points at the beginning of the WAL segment file
thatwas most recently flushed in pg_wal.  To find the most recently flushed WAL segment, first blocks of all WAL
segmentfiles in pg_wal, starting from the segment that contains currently replayed record, are inspected.  The search
stopswhen a first page with no valid header is found.
 

The benefits of starting WAL receiver early are mentioned upthread but allow me to reiterate: as WAL streaming starts,
anycommits that are waiting for synchronous replication on the master are unblocked.  The benefit of this is apparent
insituations where significant replay lag has been built up and the replication is configured to be synchronous.
 

Asim