> 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
