Re: Read access for pg_monitor to pg_replication_origin_status view

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
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 06:11:04
Message-ID: 20200609061104.GD38342@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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
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.

Also, why don't we use this occation to do the same thing for the
functions working on replication slots? While we are looking at this
area, we may as well just do it. Here is the set of functions that
would be involved:
- pg_create_physical_replication_slot
- pg_create_logical_replication_slot
- pg_replication_slot_advance
- pg_drop_replication_slot
- pg_copy_logical_replication_slot (3 functions)
- pg_copy_physical_replication_slot (2 functions)
--
Michael

Attachment Content-Type Size
rep-origin-superuser-v6.patch text/x-diff 3.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2020-06-09 06:13:35 Re: Add -Wold-style-definition to CFLAGS?
Previous Message Kyotaro Horiguchi 2020-06-09 06:09:21 Re: BUG #16481: Stored Procedure Triggered by Logical Replication is Unable to use Notification Events