From: Michael Paquier <michael@paquier.xyz>
To: Fujii Masao <masao.fujii@gmail.com>
Cc: pgsql-docs@lists.postgresql.org <pgsql-docs@lists.postgresql.org>
Subject: Re: Improve pg_stat_recovery documentation
Date: Sat, 18 Jul 2026 09:39:26 +0900
Message-ID: <alrLPjr0oG0bIrlY@paquier.xyz> (raw)
In-Reply-To: <CAHGQGwGRavm18HqnQn_f68QB96qk6arhjET1V93OJH09Mgojkg@mail.gmail.com>
References: <CAHGQGwGRavm18HqnQn_f68QB96qk6arhjET1V93OJH09Mgojkg@mail.gmail.com>
On Fri, Jul 17, 2026 at 11:10:08PM +0900, Fujii Masao wrote:
> That behavior seems fine to me, but it isn't documented. So I'd like to propose
> the attached patch, which documents that behavior and also makes a few other
> documentation improvements:
>
> - Mention the view in high-availability.sgml as a way to monitor
> recovery state and replay progress, alongside the existing recovery
> information functions.
Why not.
> - Clarify that the view returns at most one row, not exactly one row,
> and no rows to users who lack the pg_read_all_stats privilege.
Yep, that's incorrect.
> - Correct the description of last_replayed_end_lsn to clarify that it
> is the end LSN of the last replayed record plus one.
> - Document that replay_end_tli equals last_replayed_tli when no WAL
> record is currently being replayed.
Okay.
> - Clarify that current_chunk_start_time is NULL until streaming WAL
> has been received.
Time when the startup process observed that replay had caught up
- with the latest received WAL chunk. Used in recovery-conflict
- timing and replay/apply-lag diagnostics. NULL if not yet
+ with the latest WAL chunk received from streaming replication.
+ Used in recovery-conflict timing and replay/apply-lag diagnostics.
+ NULL if streaming WAL has not yet been received or the time is not
available.
[...]
- * timestamp of when we started replaying the current chunk of WAL data,
- * only relevant for replication or archive recovery
+ * timestamp of when we caught up with the latest WAL chunk received from
+ * streaming replication
*/
True that this does not work under archive recovery, so specifying
that only only gets updated due to streaming replication sounds good
here.
Looks good to me overall after reading the patch, thanks for the
suggestions.
--
Michael
Attachments:
[application/pgp-signature] signature.asc (832B, ../alrLPjr0oG0bIrlY@paquier.xyz/2-signature.asc)
download
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-docs@postgresql.org
Cc: michael@paquier.xyz, masao.fujii@gmail.com, pgsql-docs@lists.postgresql.org
Subject: Re: Improve pg_stat_recovery documentation
In-Reply-To: <alrLPjr0oG0bIrlY@paquier.xyz>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox