Re: Unnecessary delay in streaming replication due to replay lag

On Thu, Sep 11, 2025 at 5:51 PM sunil s <sunilfeb26@gmail.com> wrote:
>
> Hello Hackers,
>
> PFA rebased patch due to the code changes done in upstream commit 63599896545c7869f7dd28cd593e8b548983d613.
>
> The current status of the patch registered in Commit Fest is "Ready for Committer".

+        streamed WAL. Such environments can benefit from setting
+        <varname>wal_receiver_start_at</varname> to
+        <literal>startup</literal> or <literal>consistency</literal>. These
+        values will lead to the WAL receiver starting much earlier, and from
+        the end of locally available WAL.

When this parameter is set to 'startup' or 'consistency', what happens
if replication begins early and the startup process fails to replay
a WAL record—say, due to corruption—before reaching the replication
start point? In that case, the standby might fail to recover correctly
because of missing WAL records, while a transaction waiting for
synchronous replication may have already been acknowledged as committed.
Wouldn't that lead to a serious problem?

Regards,

--
Fujii Masao