Allow pg_read_all_stats to read replication origin status
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253352psql -h localhost -U postgresBuilt from patchset v2 (message #2), August 24, 2026 at 10:54 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253352_2 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253352_2 && git checkout t253352_2Patchset v2 (message #2) is on t253352_2
Hi,
I have been looking at the requirement for providing non-superuser
read access to specific catalog relations, specifically
pg_replication_origin_status. During this, I reviewed the capabilities
of the pg_read_all_stats role.
Looks like pg_read_all_stats was originally designed to grant access
to all pg_stats_* views, a few other monitoring views defined in
system_views.sql have been included over time. However, access to
pg_replication_origin_status remains restricted and is not currently
covered by existing roles such as pg_read_all_stats, pg_read_all_data,
or pg_monitor.
The attached patch grants pg_read_all_stats read access to the
pg_replication_origin_status view and its underlying function,
consistent with the existing approach for monitoring views in
system_views.sql. I have also included the relevant regression tests.
On pgsql-hackers, I noted a previous discussion [1]/messages/by-id/CAPdiE1zUeSycQ-VHrZQMDR4vkPthYTSxeQPXM-ZfH8QHDBCE=Q@mail.gmail.com regarding granting
this access; however, that discussion focused on the pg_monitor role
rather than pg_read_all_stats and never got commited.
[1]: /messages/by-id/CAPdiE1zUeSycQ-VHrZQMDR4vkPthYTSxeQPXM-ZfH8QHDBCE=Q@mail.gmail.com
Thanks,
Virender
Attached is the updated patch, rebased onto the latest master to fix
apply conflicts.
Commitfest entry: https://commitfest.postgresql.org/patch/7183/
Thanks,
Virender
Show quoted text
On Sat, Aug 8, 2026 at 8:16 PM Virender Singla <virender.cse@gmail.com> wrote:
Hi,
I have been looking at the requirement for providing non-superuser
read access to specific catalog relations, specifically
pg_replication_origin_status. During this, I reviewed the capabilities
of the pg_read_all_stats role.Looks like pg_read_all_stats was originally designed to grant access
to all pg_stats_* views, a few other monitoring views defined in
system_views.sql have been included over time. However, access to
pg_replication_origin_status remains restricted and is not currently
covered by existing roles such as pg_read_all_stats, pg_read_all_data,
or pg_monitor.The attached patch grants pg_read_all_stats read access to the
pg_replication_origin_status view and its underlying function,
consistent with the existing approach for monitoring views in
system_views.sql. I have also included the relevant regression tests.On pgsql-hackers, I noted a previous discussion [1] regarding granting
this access; however, that discussion focused on the pg_monitor role
rather than pg_read_all_stats and never got commited.[1] /messages/by-id/CAPdiE1zUeSycQ-VHrZQMDR4vkPthYTSxeQPXM-ZfH8QHDBCE=Q@mail.gmail.com
Thanks,
Virender