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

Thank you for your reply. I am grateful for your knowledge. 

My aim is to be able to see 

1. Is replication caught up  -->  No problems here
2. If not caught up , what is the LSN difference --> No problems here , you have already helped me 
3. If not caught up, how many bytes / KB worth of data needs to be replicated 

So far my replication runs like a dream, I am just preparing for when we transfer our mainframe tables to Postgres and
Ishould be able to answer such questions. 
 

I am just preparing myself.

LG

Ram 




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.),
FrankKettnaker, 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.),
FrankKettnaker, 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.subramanian@alte-leipziger.de
www.alte-leipziger.de
www.hallesche.de



-----Ursprüngliche Nachricht-----
Von: Laurenz Albe <laurenz.albe@cybertec.at> 
Gesendet: Dienstag, 24. März 2026 08:07
An: Subramanian,Ramachandran IT-md-db <ramachandran.subramanian@alte-leipziger.de>; pgsql-novice@lists.postgresql.org
Betreff: Re: Replication Testing- How to introduce a Lag

On Tue, 2026-03-24 at 06:14 +0000, Subramanian,Ramachandran wrote:
> 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  ) .

Right, because the LSN is not a counter that increases with each new WAL record.  It is a position in the WAL stream.
Thedifference between the LSNs of two adjacent WAL records is not 1, but the byte count of the first WAL record.
 

For example: if you insert a larger row, the LSN will advance more.
Note also that not all inserts will produce the same kind of WAL:
one insert might write a full page image to the WAL, while the next a normal insert record.

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

That's exactly what pg_wal_lsn_diff() does.

What is your worry?  What is your ultimate goal?

Yours,
Laurenz Albe