Re: Unnecessary delay in streaming replication due to replay lag

Fujii Masao <masao.fujii@gmail.com>

From: Fujii Masao <masao.fujii@gmail.com>

To: sunil s <sunilfeb26@gmail.com>

Cc: Huansong Fu <huansong.fu.info@gmail.com>, pgsql-hackers@lists.postgresql.org

Date: 2025-10-27T13:16:20Z

Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

Generate GUC tables from .dat file
- 63599896545c 19 (unreleased) cited
Skip WAL recycling and preallocation during archive recovery.
- cc2c7d65fc27 15.0 cited
Fix scenario where streaming standby gets stuck at a continuation record.
- 066871980183 11.0 cited

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