Re: Allow pg_read_all_stats to read replication origin status

Hi Virender, Kuroda-san,

I reviewed v2 of this patch.

Build and tests
---------------
The patch applies cleanly on master at 4545cee303 and builds with
--enable-cassert. make check passes (239/239 tests, including privileges).

Functional testing
------------------
On a fresh initdb cluster with the patch applied, I created an origin with
pg_replication_origin_create() and advanced it with
pg_replication_origin_advance(). Then:

- A role that is a member of pg_read_all_stats can SELECT from
pg_replication_origin_status and call
pg_show_replication_origin_status().
- A member of pg_monitor can do the same.
- A role with neither membership gets "permission denied" for both the
view and the function.
- On a separate server built without this patch, the pg_read_all_stats
member was denied on the view.

I also tested with a live logical replication setup: a publisher and a
subscriber on the same machine, with the patch on the subscriber. After
CREATE SUBSCRIPTION, a pg_read_all_stats member could see the origin that
was created automatically (pg_16401). After inserting rows on the
publisher, its remote_lsn advanced to 0/017F5920, matching the
publisher's pg_current_wal_lsn(). A role without the membership was still
denied, and the monitoring role could not read the replicated table
itself, so the grant exposes replication progress but not table data.

Regression tests
----------------
The new lines in privileges.sql check both the view and the function
before and after GRANT pg_read_all_stats, and query the view as the
granted role, in the same style as the existing pg_aios and
pg_shmem_allocations checks. I also removed the two GRANT lines from
system_views.sql while keeping the new tests, and the privileges test
failed as expected, so the tests do exercise the change.

Docs
----
I did not find text that becomes incorrect. The sentence in
func-admin.sgml already says replication origin functions are
superuser-only by default and can be granted to others. The
pg_read_all_stats description in user-manag.sgml mentions pg_stat_* views,
but that is equally true of pg_aios and the other views already granted
to the role, so it may not need a change. The patch has no doc changes,
so I did not build the docs.

pg_read_all_stats grant as proposed.
Access can be widened later more easily than it can be narrowed, and the
view is restricted today. In my testing the view showed only origin names
and LSNs and no table data, so making it public later looks low-risk if
a committer prefers that. I would leave that decision to a committer.

Thanks for working on this.

Regards,
Shubhra Jain
[image: Shubhra Jain]
Shubhra Jain
Junior Software Engineer
[image: Phone] (+91) 9752683649 <(+91)+9752683649> [image: Website]
www.ksolves.com [image: Ksolves - AI First, Always]

On Tue, Sep 29, 2026 at 1:24 PM Virender Singla <virender(dot)cse(at)gmail(dot)com>
wrote:

> > While checking the old discussion, there was alternative approach to
> export the
> > pg_replication_origin_status to public [1], which might also be good.
> local_id is
> > an internal identifier which is not sensitive, external_id is already
> public on
> > pg_replication_origin, and remote/local_lsn are also visible on other
> views.
> > Can you evaluate it also?
>
> Thanks for pointing that out. I looked at how the existing
> replication related views handle access.
>
> Open to PUBLIC (all rows, all columns):
> pg_replication_slots restart_lsn, confirmed_flush_lsn, etc.
> slotfuncs.c notes that nothing here
> should be sensitive.
> pg_stat_subscription received_lsn, latest_end_lsn
>
> Row visible to PUBLIC, LSNs need pg_read_all_stats:
> pg_stat_replication state, *_lsn, *_lag, sync_* are NULL
> without pg_read_all_stats, even for
> the user's own walsender rows. Only the
> connection columns (client_addr,
> backend_start, ...) follow the usual
> "own role or pg_read_all_stats" rule.
> pg_stat_wal_receiver all columns except pid are NULL
>
> So I don't see a single consistent rule for choosing between the two
> approaches. There are existing replication-related views following
> both models: pg_replication_slots and pg_stat_subscription expose
> replication LSNs publicly, while pg_stat_replication and
> pg_stat_wal_receiver expose only the PID publicly and require
> pg_read_all_stats for the detailed replication state and LSN
> information.
> Given this mixed precedent, granting access to pg_read_all_stats seems
> like the more conservative option for pg_replication_origin_status.
>
> Regards,
> Virender
>
>
>