From: | Greg Sabino Mullane <htamfids(at)gmail(dot)com> |
---|---|
To: | Jon Zeppieri <zeppieri(at)gmail(dot)com> |
Cc: | Nick Cleaton <nick(at)cleaton(dot)net>, pgsql-general(at)lists(dot)postgresql(dot)org |
Subject: | Re: Possible causes of high_replay lag, given replication settings? |
Date: | 2025-07-25 23:12:26 |
Message-ID: | CAKAnmm+jtytmNAYDjBkiQvCHQVwtskUzvp3J_=5mUsFvaOkRVA@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On Fri, Jul 25, 2025 at 9:57 AM Jon Zeppieri <zeppieri(at)gmail(dot)com> wrote:
> 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?
>
No - write and flush are pretty quick and simple, it's just putting the WAL
onto the local disk. Replay involves a lot more work as we have to parse
the WAL and apply the changes, which means doing a lot of I/O across many
files. Still, *hours* to me indicates more than just a lot of extra
traffic. Check that recovery_min_apply_delay is still 0, then log onto the
replica and see what's going on with regards to open transactions and locks.
Cheers,
Greg
--
Crunchy Data - https://www.crunchydata.com
Enterprise Postgres Software Products & Tech Support
From | Date | Subject | |
---|---|---|---|
Next Message | Pierre Barre | 2025-07-26 01:16:24 | Re: PostgreSQL on S3-backed Block Storage with Near-Local Performance |
Previous Message | Tom Lane | 2025-07-25 20:52:09 | Re: PostgreSQL Bug with simple function unexpectedly treating varchar parameter as an array |