Re: PostgreSQL Replication Lag – WALs Streaming but Not Being Applied

Hello,
max_standby_streaming_delay=30000ms
max_standby_archive_delay=30000ms

I had changed at some point but still failed.

Do you have any activity recorded in pg_stat_activity on the standby ? *Yes*

For the replicas displayed: only one doesn't fail.

Regards,
Musila

On Tue, Aug 18, 2026 at 9:15 PM Avinash Vallarapu <
avinash(dot)vallarapu(at)gmail(dot)com> wrote:

> Hi,
>
> Please see what the below parameters are set to (On Standby).
>
> max_standby_streaming_delay
> max_standby_archive_delay
>
> Do you have any activity recorded in pg_stat_activity on the standby ?
>
>
>
> On Tue, Aug 18, 2026 at 2:06 PM Gyanuba Gyanuba <gyanubagyanuba(at)gmail(dot)com>
> wrote:
>
>> Wait pending
>>
>> On Tue, Aug 18, 2026, 11:34 PM Simon Musila - Localhost <
>> smusila1(at)gmail(dot)com> wrote:
>>
>>> Hello,
>>>
>>> I would appreciate some guidance on an issue we are experiencing with
>>> PostgreSQL streaming replication.
>>>
>>> The standby appears to be *receiving/streaming WALs and is up to date
>>> with the primary*, but the WAL records are not being applied to the
>>> standby, resulting in an increasing replication/replay lag.
>>>
>>> We have confirmed that:
>>>
>>> - WALs are being streamed from the primary to the standby.
>>> - The WAL receiver appears to be active.
>>> - The standby is receiving the WALs, but the replay/apply process is
>>> not keeping up.
>>> - pg_stat_database_conflicts shows no conflicts.
>>> - pg_is_wal_replay_paused() returns false.
>>> - recovery_min_apply_delay is 0.
>>> - hot_standby_feedback is disabled.
>>>
>>> [image: Screenshot 2026-08-18 at 20.52.58.png]
>>>
>>> *My questions are:*
>>>
>>> 1. What could cause WALs to be successfully streamed to the standby
>>> but not applied/replayed?
>>> 2. What are the best steps to identify what the WAL replay process
>>> is waiting on?
>>> 3. Is restarting the replication/standby the only practical
>>> solution, or is there a way to safely resume WAL replay without restarting?
>>> 4. Are there specific PostgreSQL views, wait events, or system
>>> metrics that you would recommend checking to identify the bottleneck?
>>>
>>> I would appreciate any guidance on troubleshooting this and identifying
>>> the underlying cause rather than simply restarting the replication whenever
>>> this occurs.
>>>
>>> *NB: This happens on a daily basis!*
>>>
>>> Thank you in advance.
>>>
>>> Regards,
>>> Musila
>>>
>>
>
> --
> Regards,
> Avinash Vallarapu
> HexaCluster Corp.
> www.hexacluster.ai
>