| From: | Virender Singla <virender(dot)cse(at)gmail(dot)com> |
|---|---|
| To: | "Hayato Kuroda (Fujitsu)" <kuroda(dot)hayato(at)fujitsu(dot)com> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Dilip Kumar <DilipBalaut(at)gmail(dot)com> |
| Subject: | Re: Allow pg_read_all_stats to read replication origin status |
| Date: | 2026-09-18 10:26:43 |
| Message-ID: | CAM6Zo8zrOuehNZXfaYY16JP1+jWjbOLUZS3xyoRCGkNqbHJfTg@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Thanks Hayato for taking a look.
> Not sure, does pg_replication_origin_status contain statistics? I expected
> statistics means some cumulative data, but this view contains node ids and LSNs.
I observed that there are other similar views granted read privileges
to pg_read_all_stats [1]. Views like pg_shmem_allocations,
pg_backend_memory_contexts, and pg_aios are real-time, point-in-time
snapshots of the system's internal state. It looks like the definition
of "stats" for this role has practically evolved to cover general
system observability, monitoring, and telemetry data. Also,
pg_read_all_stats is granted to pg_monitor anyway.
> Can you give us a background why the idea allowing pg_monitor to read the view
> was not accepted?
There actually was prior discussion on granting this to
pg_read_all_stats instead of pg_monitor. However, the work was split
across multiple changes. The first change, which related to removing
the hardcoded superuser check, was committed, but the thread stalled
before the second change (granting access to pg_read_all_stats) could
be completed.
[1] https://github.com/postgres/postgres/blob/master/src/backend/catalog/system_views.sql
Thanks,
Virender
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2026-09-18 10:26:54 | Stabilize and shorten test_checksums/013_rewind test |
| Previous Message | shveta malik | 2026-09-18 09:58:38 | Re: Proposal: Conflict log history table for Logical Replication |