Feedback-ID: i0fe9450f:Fastmail
Date: Sat, 18 Jul 2026 09:39:26 +0900
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
Message-ID: <alrLPjr0oG0bIrlY@paquier.xyz>
References: 
 <CAHGQGwGRavm18HqnQn_f68QB96qk6arhjET1V93OJH09Mgojkg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="fuBQyWkWBdGzcZ5h"
Content-Disposition: inline
In-Reply-To: 
 <CAHGQGwGRavm18HqnQn_f68QB96qk6arhjET1V93OJH09Mgojkg@mail.gmail.com>
Archived-At: 
 <https://www.postgresql.org/message-id/alrLPjr0oG0bIrlY%40paquier.xyz>
Precedence: bulk

--fuBQyWkWBdGzcZ5h
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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 p=
ropose
> the attached patch, which documents that behavior and also makes a few ot=
her
> documentation improvements:
>=20
> - 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

--fuBQyWkWBdGzcZ5h
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEG72nH6vTowiyblFKnvQgOdbyQH0FAmpayz4ACgkQnvQgOdby
QH15FA/9FA5JCy4qyJrGxVVoQ8MFerWiJVfJg4HTgpZIVp9wL5JZi+NAoiDs1Sy5
V78KZE8VfjDrHihXpVdUzsOkKzrtiqdAcc34TSGAdjdki/hzVObFCXfgSOglBsLk
rcMemGl/P8DtZM8aWOQsBdQYyfAE4qZ8libgAAWowXZ+wItn//Q/kSwA0tnP14P+
/baNQoY37I6La/SDFvDPrpLZe1m7VuK08V75AFDPUe8lWxt3NFMTTuPtD9uReZMa
77oM0OmURQAt0OQzlKewqmt2p51tt5YASI+S2vhhMMLkcgvzL1KvW0NPBttKKYWn
VLhnVm8msjYpkqD/CWtm7V90Rr+JO3EiQQi5Oq9dTToV7s5CbxbSWejb3Qn4jBN2
eKcbTbDOi89VDt8+Dbau2qRnqDnfxh5Fk0kfu75d/ZHz9lKEVZic8VNlStAQMhCb
lZlZurRWsJpbDOJ/FOy6PkygM5SSjKgGvMQ6YJtkgROcC2Gtz9+w5vrrhVD3u+SY
q2P+YrbGNhiDsnI0Q0LOosc/Y79mJI8qsim4zAmP+lneCkO134cOR5FCSwlSTP2+
c0/69DgftCsT0e9g0QGt2jCtK/fab7w2lYgleZHZfknVz2Wsq97znvxbtvFFx1WF
SxFZcVWUPbTwvd7EyGLNMQIvb0eiMAFCXsX+5qvsFkRxe5+xNGg=
=0hKA
-----END PGP SIGNATURE-----

--fuBQyWkWBdGzcZ5h--