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

From Martín Marqués
Subject Re: Read access for pg_monitor to pg_replication_origin_status view
Date
Msg-id CAPdiE1zUeSycQ-VHrZQMDR4vkPthYTSxeQPXM-ZfH8QHDBCE=Q@mail.gmail.com
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
List pgsql-hackers
Hi Kyotaro-san,

Thank you for taking the time to review my patches. Would you like to
set yourself as a reviewer in the commit entry here?
https://commitfest.postgresql.org/28/2577/

> 0002:
>
> It is forgetting to grant pg_read_all_stats to execute
> pg_show_replication_origin_status.  As the result pg_read_all_stats
> gets error on executing the function, not on doing select on the view.

Seems I was testing on a cluster where I had already been digging, so
pg_real_all_stats had execute privileges on
pg_show_replication_origin_status (I had manually granted that) and
didn't notice because I forgot to drop the cluster and initialize
again.

Thanks for the pointer here!

> 0003:
>
> It seems to be a take-after of adminpack's documentation, but a
> superuser is not the only one on PostgreSQL.  The something like the
> description in 27.2.2 Viewing Statistics looks more suitable.
>
> > Superusers and members of the built-in role pg_read_all_stats (see
> > also Section 21.5) can see all the information about all sessions.
>
> Section 21.5 is already saying as follows.
>
> > pg_monitor
> >   Read/execute various monitoring views and functions. This role is a
> >   member of pg_read_all_settings, pg_read_all_stats and
> >   pg_stat_scan_tables.

I'm not sure if I got this right, but I added some more text to point
out that the pg_read_all_stats role can also access one specific
function. I personally think it's a bit too detailed, and if we wanted
to add details it should be formatted differently, which would require
a more invasive patch (would prefer leaving that out, as it might even
mean moving parts which are not part of this patch).

In any case, I hope the change fits what you've kindly pointed out.

> 0004:
>
> Looks fine by me.

Here goes v3 of the patch

--
Martín Marqués                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

Attachment

pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Expand the use of check_canonical_path() for more GUCs
Next
From: Mark Dilger
Date:
Subject: Towards easier AMs: Cleaning up inappropriate use of name "relkind"