MIME-Version: 1.0
References: <CAKfDxxwF03mouH7GqdZ0AqpGKz2wTj4T3F6ei_ubEQnNtErfGA@mail.gmail.com>
In-Reply-To: <CAKfDxxwF03mouH7GqdZ0AqpGKz2wTj4T3F6ei_ubEQnNtErfGA@mail.gmail.com>
From: Nick Cleaton <nick@cleaton.net>
Date: Wed, 23 Jul 2025 21:27:44 +0100
Message-ID: <CAFgz3ksSB1OvN1ONDOO2qvhhF-FS7PXQTQtkDQYP_Y_pcvf+6g@mail.gmail.com>
Subject: Re: Possible causes of high_replay lag, given replication settings?
To: Jon Zeppieri <zeppieri@gmail.com>
Cc: pgsql-general@lists.postgresql.org
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAFgz3ksSB1OvN1ONDOO2qvhhF-FS7PXQTQtkDQYP_Y_pcvf%2B6g%40mail.gmail.com>
Precedence: bulk

On Fri, 18 Jul 2025 at 21:29, Jon Zeppieri <zeppieri@gmail.com> wrote:
>
> I just had a situation where physical replication fell far behind
> (hours). The write and flush lag times were 0, but replay_lag was
> high. The replica has hot_standby_feedback on, and both
> max_standby_streaming_delay and max_standby_archive_delay are set to
> 30s.
>
> What could cause a situation like this? If the network were a problem,
> I'd expect the other _lag times to be high. So it appears that the
> replica was getting the WAL but was unable to apply it. Are there
> situations where the replica cannot apply WAL other than the kinds of
> conflicts that would be addressed by the _delay settings?
>
> I checked pg_stat_database_conflicts, but there was nothing in it -- all zeros.

This can happen when there are several busy writing processes on the
primary. The single replay process on the replica can't keep up with
the writes.