Hi, PostgreSQL 19 added pg_stat_recovery to expose the current state of WAL replay, including the last replayed record and the record currently being replayed [1]. This patch is a follow-up to that work. The origin of the current redo session is currently reported only through the "redo starts at" server log message. redo_start_lsn deliberately exposes through SQL a fact that is already available in that log message. The design question behind this patch is whether the fixed origin of a redo session should be queryable alongside the moving replay positions in pg_stat_recovery, or whether the server log is a sufficient interface for that information.
This leaves a monitoring client able to answer "where is replay now?", but not "what WAL range has this recovery session replayed?". In particular, there is no SQL-visible value that can be paired with the current replay LSN to report progress through a known, fixed WAL range, associate live recovery activity with the corresponding range examined by pg_walinspect or pg_waldump, identify the timeline on which redo began or measure how long the current redo session has been active. The timeline is needed because an LSN alone does not identify a WAL history after a timeline switch. The start time provides the age of this redo session without treating the startup process's lifetime as an equivalent measurement. The existing log message is persistent and is also available for crash recovery, where pg_stat_recovery normally cannot be queried before recovery finishes. The proposed fields do not replace that log. Their narrower use is live SQL monitoring, particularly when a client has database access but does not have direct access to the server log, or wants to obtain the redo origin and current replay position through one structured interface. This patch adds three fields to pg_stat_recovery - redo_start_time, redo_start_lsn and redo_start_tli. The values are set when the first WAL record is selected for replay. redo_start_lsn therefore matches the existing "redo starts at" log message. The fields remain NULL until a record is selected and stay NULL when redo is not required. The patch does not add prediction, ETA, recovery-type classification, or per-record counters. It exposes only objective origin facts for the current redo session. An external monitoring tool may use these facts when presenting progress through a fixed target, but any prediction remains outside core. Like the existing pg_stat_recovery fields, these values describe only the current recovery session. They are not retained after recovery ends. The patch therefore does not attempt to provide completed crash-recovery history. The collection cost is limited to recording the three values once per redo session. No additional work is performed for each replayed WAL record. The recovery TAP test verifies that the fields are populated on a standby and that redo_start_lsn matches the server log. Kindly review and share the feedback. [1] https://www.postgresql.org/message-id/CABPTF7W%2BNody-%2BP9y4PNk37-QWuLpfUrEonHuEhrX%2BVx9Kq%2BKw%40mail.gmail.com Best Regards, Nitin Jadhav Azure Database for PostgreSQL Microsoft
v1-0001-Expose-redo-start-information-in-pg_stat_recovery.patch
Description: Binary data
