MIME-Version: 1.0
References: <CAKfDxxwF03mouH7GqdZ0AqpGKz2wTj4T3F6ei_ubEQnNtErfGA@mail.gmail.com>
 <CAFgz3ksSB1OvN1ONDOO2qvhhF-FS7PXQTQtkDQYP_Y_pcvf+6g@mail.gmail.com> <CAKfDxxxqWnf2Wb8dg2Ytx497aPpb-eFugxYVJfC=Pi8DaciXyg@mail.gmail.com>
In-Reply-To: <CAKfDxxxqWnf2Wb8dg2Ytx497aPpb-eFugxYVJfC=Pi8DaciXyg@mail.gmail.com>
From: Greg Sabino Mullane <htamfids@gmail.com>
Date: Fri, 25 Jul 2025 19:12:26 -0400
Message-ID: <CAKAnmm+jtytmNAYDjBkiQvCHQVwtskUzvp3J_=5mUsFvaOkRVA@mail.gmail.com>
Subject: Re: Possible causes of high_replay lag, given replication settings?
To: Jon Zeppieri <zeppieri@gmail.com>
Cc: Nick Cleaton <nick@cleaton.net>, pgsql-general@lists.postgresql.org
Content-Type: multipart/alternative; boundary="00000000000072fdb8063ac915b7"
Archived-At: <https://www.postgresql.org/message-id/CAKAnmm%2BjtytmNAYDjBkiQvCHQVwtskUzvp3J_%3D5mUsFvaOkRVA%40mail.gmail.com>
Precedence: bulk

--00000000000072fdb8063ac915b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Fri, Jul 25, 2025 at 9:57=E2=80=AFAM Jon Zeppieri <zeppieri@gmail.com> w=
rote:

> 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

--00000000000072fdb8063ac915b7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jul 25, 2025 at 9:57=E2=80=AFAM J=
on Zeppieri &lt;<a href=3D"mailto:zeppieri@gmail.com">zeppieri@gmail.com</a=
>&gt; wrote:</div><div class=3D"gmail_quote gmail_quote_container"><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
 solid rgb(204,204,204);padding-left:1ex">Thanks for the response, Nick. I&=
#39;m curious why the situation you describe wouldn&#39;t also lead to the =
write_lag and flush_lag also being<br>
high. If the problem is simply keeping up with the primary, wouldn&#39;t yo=
u expect all three lag times to be elevated?<br></blockquote><div><br></div=
><div>No - write and flush are pretty quick and simple, it&#39;s just putti=
ng 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 acro=
ss many files. Still, *hours* to me indicates more than just a lot of extra=
 traffic. Check that=C2=A0recovery_min_apply_delay is still 0, then log ont=
o the replica and see what&#39;s going on with regards to open transactions=
 and locks.</div><div>=C2=A0</div></div><div dir=3D"ltr" class=3D"gmail_sig=
nature"><div dir=3D"ltr"><div>Cheers,</div><div>Greg</div><div><br></div><d=
iv>--</div><div>Crunchy Data - <a href=3D"https://www.crunchydata.com" targ=
et=3D"_blank">https://www.crunchydata.com</a></div><div>Enterprise Postgres=
 Software Products &amp; Tech Support</div><div><br></div></div></div></div=
>

--00000000000072fdb8063ac915b7--