Re: Possible causes of high_replay lag, given replication settings? - Mailing list pgsql-general

From Jon Zeppieri
Subject Re: Possible causes of high_replay lag, given replication settings?
Date
Msg-id CAKfDxxxqWnf2Wb8dg2Ytx497aPpb-eFugxYVJfC=Pi8DaciXyg@mail.gmail.com
Whole thread Raw
In response to Re: Possible causes of high_replay lag, given replication settings?  (Nick Cleaton <nick@cleaton.net>)
Responses Re: Possible causes of high_replay lag, given replication settings?
List pgsql-general
On Wed, Jul 23, 2025 at 4:27 PM Nick Cleaton <nick@cleaton.net> wrote:
>
> 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.

Thanks for the response, Nick. I'm curious why the situation you
describe wouldn't also lead to the write_lag and flush_lag also being
high. If the problem is simply keeping up with the primary, wouldn't
you expect all three lag times to be elevated?

- Jon



pgsql-general by date:

Previous
From: Mark
Date:
Subject: Re: Upper / lower case keys in JSON objects
Next
From: Laurenz Albe
Date:
Subject: Re: Sorting by respecting diacritics/accents