From: | Nick Cleaton <nick(at)cleaton(dot)net> |
---|---|
To: | Jon Zeppieri <zeppieri(at)gmail(dot)com> |
Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Possible causes of high_replay lag, given replication settings? |
Date: | 2025-07-23 20:27:44 |
Message-ID: | CAFgz3ksSB1OvN1ONDOO2qvhhF-FS7PXQTQtkDQYP_Y_pcvf+6g@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, 18 Jul 2025 at 21:29, Jon Zeppieri <zeppieri(at)gmail(dot)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.
From | Date | Subject | |
---|---|---|---|
Next Message | sivapostgres@yahoo.com | 2025-07-24 12:18:52 | Re: Is there any limit on the number of rows to import using copy command |
Previous Message | Merlin Moncure | 2025-07-23 17:49:49 | Re: Is there any limit on the number of rows to import using copy command |