public inbox for pgsql-novice@postgresql.org  
help / color / mirror / Atom feed
From: Subramanian,Ramachandran <ramachandran.subramanian@alte-leipziger.de>
To: Laurenz Albe <laurenz.albe@cybertec.at>
To: pgsql-novice@lists.postgresql.org <pgsql-novice@lists.postgresql.org>
Subject: AW: Replication Testing- How to introduce a Lag
Date: Tue, 24 Mar 2026 17:01:07 +0000
Message-ID: <003a3038c353448cb2b7cf0e1a179f98@alte-leipziger.de> (raw)
In-Reply-To: <2fb6a2f5eb2c9a1cbe701a237c74223d121ca918.camel@cybertec.at>
References: <aadb9058660d4e10b5cee44b82458802@alte-leipziger.de>
	<f3927bc3a9baf4400325b91652869907f0581c97.camel@cybertec.at>
	<e1e41761323040228570cf6a7e02518e@alte-leipziger.de>
	<8b38fa5141905f9ad6983b8d5ae944e812e3d28a.camel@cybertec.at>
	<fa47fe18078043adbdfe007b7270ffd0@alte-leipziger.de>
	<fc42f77c80fdb3c0267148b807edfacc49b0b0ca.camel@cybertec.at>
	<fc3be1f56ded49dc9be519f92d8b9ab4@alte-leipziger.de>
	<0e00fcc0062b59b88f98dba4900ce49d5a9a3fea.camel@cybertec.at>
	<477369bf897b44feb2d2368f6fca93fc@alte-leipziger.de>
	<89d63402747edb3bf80ff668fdd63cc77334f446.camel@cybertec.at>
	<aa307627991c41f280bb6da27ebc9b1d@alte-leipziger.de>
	<013104103e016e84d59c1e2accb0b1b1f99d9870.camel@cybertec.at>
	<39ec6185a893473aa9217520e5a92be7@alte-leipziger.de>
	<2fb6a2f5eb2c9a1cbe701a237c74223d121ca918.camel@cybertec.at>

I am setting the recovery_min_apply_delay ONLY to simulate/force a delay , because I cannot test my process otherwise. 

Without this parameter the replication is happening in near real time and I can never test the part of the monitor/Health check that is supposed to wake up and report a delay.

Once I have tested my monitoring process, I will run it with no delay. 

My question is , can the difference in LSN from this query approximated to the amount of data that is yet to be transferred

select  pg_wal_lsn_diff(pg_current_wal_lsn(),replay_lsn) from pg_stat_replication

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.), 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.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 17:42
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 07:51 +0000, Subramanian,Ramachandran wrote:
> 3. If not caught up, how many bytes / KB worth of data needs to be 
> replicated

Please define "caught up", in particular how you understand the term in the presence of recovery_min_apply_delay, which you said you are setting.
The point of the parameter is to *prevent* WAL replay from catching up.

Yours,
Laurenz Albe


reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-novice@postgresql.org
  Cc: ramachandran.subramanian@alte-leipziger.de, laurenz.albe@cybertec.at, pgsql-novice@lists.postgresql.org
  Subject: Re: AW: Replication Testing- How to introduce a Lag
  In-Reply-To: <003a3038c353448cb2b7cf0e1a179f98@alte-leipziger.de>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox