Message-ID: <89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at>
Subject: Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
From: Laurenz Albe <laurenz.albe@cybertec.at>
To: "Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>,
  "pgsql-novice@lists.postgresql.org"	 <pgsql-novice@lists.postgresql.org>
Date: Mon, 23 Mar 2026 22:59:54 +0100
In-Reply-To: <477369bf897b44feb2d2368f6fca93fc@alte-leipziger.de>
References: <aadb9058660d4e10b5cee44b82458802@alte-leipziger.de>
				 <f3927bc3a9baf4400325b91652869907f0581c97.camel@cybertec.at>
				 <e1e41761323040228570cf6a7e02518e@alte-leipziger.de>
			 <8b38fa5141905f9ad6983b8d5ae944e812e3d28a.camel@cybertec.at>
			 <fa47fe18078043adbdfe007b7270ffd0@alte-leipziger.de>
		 <fc42f77c80fdb3c0267148b807edfacc49b0b0ca.camel@cybertec.at>
		 <fc3be1f56ded49dc9be519f92d8b9ab4@alte-leipziger.de>
	 <0e00fcc0062b59b88f98dba4900ce49d5a9a3fea.camel@cybertec.at>
	 <477369bf897b44feb2d2368f6fca93fc@alte-leipziger.de>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.58.3 (3.58.3-1.fc43) 
MIME-Version: 1.0
Archived-At: 
 <https://www.postgresql.org/message-id/89d63402747edb3bf80ff668fdd63cc77334f446.camel%40cybertec.at>
Precedence: bulk

On Mon, 2026-03-23 at 16:36 +0000, Subramanian,Ramachandran wrote:
> I noticed that=C2=A0 RBAs are not incremented one for one . i.e=C2=A0 1 r=
ow inserted does not mean RBA=3DRBA+1 . 1 row updated=C2=A0 does not mean R=
BA=3DRBA+1=20
>=20
> I have ALTER SYSTEM SET recovery_min_apply_delay=3D300000 ; ( on the stan=
d by side )=20
>=20
> On the Source side=20
> A simple create table results in a RBA difference of 108328=20
>=20
> A simple insert of 1 row results in a RBA difference of 296=C2=A0=C2=A0 s=
ometimes 96=20
>=20
> Is there a way to estimate roughly the amount of data that remains to be =
transfered ?=C2=A0

I don't know what an RBA is...

If you are using recovery_min_apply_delay, don't measure the replication la=
g
with regard to the replay_lsn, because replay is deliberately delayed.
Instead, measure the difference to flush_lsn, the WAL position successfully
transferred to the standby and persisted there.

Yours,
Laurenz Albe