Horton

Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag

Laurenz Albe <laurenz.albe@cybertec.at>

View thread View on postgr.es
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: 2026-03-23T21:59:54Z
Lists: pgsql-novice 
On Mon, 2026-03-23 at 16:36 +0000, Subramanian,Ramachandran wrote:
> I noticed that  RBAs are not incremented one for one . i.e  1 row inserted does not mean RBA=RBA+1 . 1 row updated  does not mean RBA=RBA+1 
> 
> I have ALTER SYSTEM SET recovery_min_apply_delay=300000 ; ( on the stand by side ) 
> 
> On the Source side 
> A simple create table results in a RBA difference of 108328 
> 
> A simple insert of 1 row results in a RBA difference of 296   sometimes 96 
> 
> Is there a way to estimate roughly the amount of data that remains to be transfered ? 

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

If you are using recovery_min_apply_delay, don't measure the replication lag
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