Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag - Mailing list pgsql-novice

From Laurenz Albe
Subject Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
Date
Msg-id 89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at
Whole thread Raw
In response to AW: AW: AW: AW: Replication Testing- How to introduce a Lag  ("Subramanian,Ramachandran" <ramachandran.subramanian@alte-leipziger.de>)
Responses AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
List 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 
doesnot 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



pgsql-novice by date:

Previous
From: "Subramanian,Ramachandran"
Date:
Subject: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
Next
From: "Subramanian,Ramachandran"
Date:
Subject: AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag