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

From: "Subramanian,Ramachandran" <ramachandran(dot)subramanian(at)alte-leipziger(dot)de>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, "pgsql-novice(at)lists(dot)postgresql(dot)org" <pgsql-novice(at)lists(dot)postgresql(dot)org>
Subject: AW: AW: AW: AW: AW: Replication Testing- How to introduce a Lag
Date: 2026-03-24 06:14:23
Message-ID: aa307627991c41f280bb6da27ebc9b1d@alte-leipziger.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-novice


By force of habit I used a mainframe term. I am sorry . RBA = Relative Byte Address. Used as Log Sequence Number.

I noticed that if I insert one row in a table at the source, the difference in LSNs is not 1 . ( with a delibrately introduced delay on the apply side ),

It is sometimes 96, sometimes 296 ( for the same table two inserts ) .

psql -h $SOURCE_HOST -p $SOURCE_PORT -c "select pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) from pg_stat_replication"

Is there a method to calculate the APPROXIMATE amount of data in ( Bytes ) that are yet to be transfered from Source to Standby ?

LG

Ram
[Subramanian,Ramachandran IT-md-db]

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

Freundliche Grüße

i. A. Ramachandran Subramanian
Zentralbereich Informationstechnologie

Alte Leipziger Lebensversicherung a.G.

Hallesche Krankenversicherung a.G.

Alte Leipziger Lebensversicherung a.G., Alte Leipziger-Platz 1, 61440 Oberursel
Vors. des Aufsichtsrats: Dr. Walter Botermann · Vorstand: Christoph Bohn (Vors.), Dr. Jürgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander Mayer, Christian Pape, Wiltrud Pekarek, Udo Wilcsek
Sitz Oberursel (Taunus) · Rechtsform VVaG · Amtsgericht Bad Homburg v. d. H. HRB 1583 · USt.-IdNr. DE 114106814


Hallesche Krankenversicherung a.G., Löffelstraße 34-38, 70597 Stuttgart
Vors. des Aufsichtsrats: Dr. Walter Botermann · Vorstand: Christoph Bohn (Vors.), Dr. Jürgen Bierbaum (stv. Vors.), Frank Kettnaker, Dr. Jochen Kriegmeier, Alexander Mayer, Christian Pape,
Wiltrud Pekarek, Udo Wilcsek
Sitz Stuttgart · Rechtsform VVaG · Amtsgericht Stuttgart HRB 2686 · USt.-IdNr. DE 147802285
Beiträge zu privaten Kranken- und Pflegekrankenversicherungen unterliegen nicht der Versicherungsteuer (§ 4 Nr. 5 VersStG) · Versicherungsleistungen sowie Umsätze aus Versicherungsvertreter-/Maklertätigkeiten sind umsatzsteuerfrei


Die Pflichtangaben der ALH Gruppe gemäß § 35a GmbHG bzw. § 80 AktG finden Sie hier: https://www.alte-leipziger.de/impressum

______________________

ALH Gruppe
Alte Leipziger-Platz 1, 61440 Oberursel
Tel.: +49 (6171) 66-4882
Fax: +49 (6171) 66-800-4882
E-Mail: ramachandran(dot)subramanian(at)alte-leipziger(dot)de
www.alte-leipziger.de
www.hallesche.de

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Laurenz Albe 2026-03-24 07:07:00 Re: Replication Testing- How to introduce a Lag
Previous Message Laurenz Albe 2026-03-23 21:59:54 Re: AW: AW: AW: AW: Replication Testing- How to introduce a Lag