Re: Read access for pg_monitor to pg_replication_origin_status view

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: michael(at)paquier(dot)xyz
Cc: masahiko(dot)sawada(at)2ndquadrant(dot)com, martin(at)2ndquadrant(dot)com, sfrost(at)snowman(dot)net, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Read access for pg_monitor to pg_replication_origin_status view
Date: 2020-06-09 08:34:13
Message-ID: 20200609.173413.2271421887940326555.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Tue, 9 Jun 2020 15:11:04 +0900, Michael Paquier <michael(at)paquier(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Kyotaro Horiguchi 2020-06-09 08:53:01 Re: Bump default wal_level to logical
Previous Message David Rowley 2020-06-09 08:27:12 Re: WIP: Generic functions for Node types using generated metadata