| From: | Nitin Jadhav <nitinjadhavpostgres(at)gmail(dot)com> |
|---|---|
| To: | Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Reporting WAL replay progress during pre-consistency standby reovery |
| Date: | 2026-10-08 10:35:17 |
| Message-ID: | CAMm1aWausyBGo15ik7Y13JZEb2_UO2POSOSK6ONkdftSGfO6Pg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
Periodic replay progress reporting could be useful when a new standby
remains unavailable for a long time before reaching consistency. SQL
monitoring is not yet available during this period, and it can be
difficult to determine from the standby logs whether WAL replay is
advancing.
PostgreSQL already periodically reports:
redo in progress, elapsed time: ..., current LSN: ...
during non-standby recovery. This is intentionally suppressed in
standby mode because a standby can remain in recovery indefinitely,
which could result in unbounded logging.
Would it make sense to emit the existing message only while a standby
has not yet reached consistency, and disable the progress timer as
soon as consistency is reached?
This would help particularly while replaying WAL from pg_wal, for
which there is no per-segment LOG message. During archive recovery,
"restored log file ..." indicates retrieval rather than the current
replay position. Once streaming starts, the primary may expose
replay_lsn through pg_stat_replication, but that does not cover the
earlier local/archive replay period.
The proposal would reuse log_startup_progress_interval and report only
the elapsed time and current replay LSN and it would preserve the
current no-periodic-reporting behavior after consistency.
Does this seem like a useful observability improvement, or is there an
existing way to obtain equivalent replay progress during this period?
If this seems useful, I would be happy to prepare and share a patch.
Best Regards,
Nitin Jadhav
Microsoft
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2026-10-08 10:58:28 | Re: [PATCH] Extensible ReadyForQuery wire protocol message and C hook, for connection pools and WAIT FOR LSN |
| Previous Message | Heikki Linnakangas | 2026-10-08 10:06:55 | Re: Fix a wal_debug crash with the new shmem allocation API |