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

From Michael Paquier
Subject Re: Read access for pg_monitor to pg_replication_origin_status view
Date
Msg-id 20200609061104.GD38342@paquier.xyz
Whole thread Raw
In response to Re: Read access for pg_monitor to pg_replication_origin_status view  (Kyotaro Horiguchi <horikyota.ntt@gmail.com>)
Responses Re: Read access for pg_monitor to pg_replication_origin_status view
Re: Read access for pg_monitor to pg_replication_origin_status view
List 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

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Atomic operations within spinlocks
Next
From: Andres Freund
Date:
Subject: Re: Add -Wold-style-definition to CFLAGS?