| From: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
|---|---|
| To: | "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org> |
| Subject: | Improve pg_stat_recovery documentation |
| Date: | 2026-07-17 14:10:08 |
| Message-ID: | CAHGQGwGRavm18HqnQn_f68QB96qk6arhjET1V93OJH09Mgojkg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-docs |
Hi,
While trying the new pg_stat_recovery view in v19, I found that it can return
no rows even while recovery is in progress. This happened because the user
querying the view lacked the pg_read_all_stats privilege.
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.
- 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.
- 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.
- Clarify that current_chunk_start_time is NULL until streaming WAL
has been received.
Thought?
Regards,
--
Fujii Masao
| Attachment | Content-Type | Size |
|---|---|---|
| v1-0001-doc-Improve-pg_stat_recovery-documentation.patch | application/octet-stream | 7.2 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | PG Doc comments form | 2026-07-18 00:13:00 | Incorrect grammar |
| Previous Message | Fujii Masao | 2026-07-16 04:47:11 | Re: Clarify log_parameter_max_length docs regarding log_min_duration_statement vs log_duration |