Re: Read access for pg_monitor to pg_replication_origin_status view - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Read access for pg_monitor to pg_replication_origin_status view
Date
Msg-id 20200609.173413.2271421887940326555.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Read access for pg_monitor to pg_replication_origin_status view  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
At Tue, 9 Jun 2020 15:11:04 +0900, Michael Paquier <michael@paquier.xyz> wrote in 
> On Mon, Jun 08, 2020 at 05:44:56PM +0900, Kyotaro Horiguchi wrote:
> > Mmm. Right.
> 
> Yep.  I bumped on that myself.  I am not sure about 0002 and 0004 yet,
> and IMO they are not mandatory pieces, but from what I can see in the
> set 0001 and 0003 can just be squashed together to remove those
> superuser checks, and no spots within the twelve functions calling
> replorigin_check_prerequisites() are missing a REVOKE.  So something
> like the attached could just happen first, no?  If the rights of

It looks fine to me.

> pg_read_all_stats need to be extended, it would always be possible to
> do so once the attached is done with a custom script.

The depends on whether it is valid and safe (and useful) to reveal the
view to pg_read_all_stats. If that is the case the additional
privilege should be granted for the monitoring sake by default.  And I
think revealing the view to the role is valid and safe, and useful.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: David Rowley
Date:
Subject: Re: WIP: Generic functions for Node types using generated metadata
Next
From: Kyotaro Horiguchi
Date:
Subject: Re: Bump default wal_level to logical