| From: | Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> |
|---|---|
| To: | "Subramanian,Ramachandran" <ramachandran(dot)subramanian(at)alte-leipziger(dot)de>, "pgsql-novice(at)lists(dot)postgresql(dot)org" <pgsql-novice(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag |
| Date: | 2026-03-23 21:59:54 |
| Message-ID: | 89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| 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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Subramanian,Ramachandran | 2026-03-24 06:14:23 | AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag |
| Previous Message | Subramanian,Ramachandran | 2026-03-23 16:36:22 | AW: AW: AW: AW: Replication Testing- How to introduce a Lag |