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: Replication Testing- How to introduce a Lag
Date: 2026-03-24 17:01:07
Message-ID: 003a3038c353448cb2b7cf0e1a179f98@alte-leipziger.de
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-novice

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(dot)subramanian(at)alte-leipziger(dot)de
www.alte-leipziger.de
www.hallesche.de

-----Ursprüngliche Nachricht-----
Von: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>
Gesendet: Dienstag, 24. März 2026 17:42
An: Subramanian,Ramachandran IT-md-db <ramachandran(dot)subramanian(at)alte-leipziger(dot)de>; pgsql-novice(at)lists(dot)postgresql(dot)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

In response to

Responses

Browse pgsql-novice by date

  From Date Subject
Next Message Laurenz Albe 2026-03-25 06:04:14 Re: AW: Replication Testing- How to introduce a Lag
Previous Message Laurenz Albe 2026-03-24 16:41:51 Re: Replication Testing- How to introduce a Lag