| From: | hubert depesz lubaczewski <depesz(at)depesz(dot)com> |
|---|---|
| To: | Bilal Abdulkadir Muhammed <bilalabdulkadir286(at)gmail(dot)com> |
| Cc: | pgsql-general(at)lists(dot)postgresql(dot)org |
| Subject: | Re: Question about monitoring PostgreSQL 10 streaming replication health |
| Date: | 2026-07-21 09:08:00 |
| Message-ID: | al828K45DEMDdIB_@depesz.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Mon, Jul 20, 2026 at 05:23:07PM +0300, Bilal Abdulkadir Muhammed wrote:
> I am monitoring a PostgreSQL 10 standby server using:
>
> pg_last_xlog_receive_location()
> and
> pg_last_xlog_replay_location()
>
> The current query only checks replay lag. I would like guidance on a more
> comprehensive monitoring approach that can detect:
>
> 1. Standby disconnected from the primary.
You can see this in https://pgdoc.link/pg_stat_replication(at)10
> 2. WAL receiver process stopped.
Not sure how this is different than #1
> 3. Required WAL segment removed from the primary
> (for example: "requested WAL segment has already been removed").
Check logs, and also check for existence of streaming.
> I would like to know:
> - Which SQL checks are recommended for these scenarios?
> - Which conditions require external monitoring or log analysis?
I would always monitor logs for errors.
> - What is the recommended practice for monitoring PostgreSQL 10 streaming
> replication health?
The recommended practice is to upgrade. Pg 10 stopped being *supported*
almost 4 years ago!
Upgrade to something that is supported. Preferably newest possible (18
now, 19 by the end of this year).
Best regards,
depesz
| From | Date | Subject | |
|---|---|---|---|
| Next Message | aadish ajay | 2026-07-23 20:56:30 | Feedback wanted: a framework where Postgres is the entire backend (no ORM/API layer) |
| Previous Message | Bilal Abdulkadir Muhammed | 2026-07-20 14:23:07 | Question about monitoring PostgreSQL 10 streaming replication health |