Re: pg_walinspect - a new extension to get raw WAL data and WAL stats
Stephen Frost <sfrost@snowman.net>
From: Stephen Frost <sfrost@snowman.net>
To: Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>
Cc: Jeff Davis <pgsql@j-davis.com>, Robert Haas <robertmhaas@gmail.com>, Ashutosh Sharma <ashu.coek88@gmail.com>, Andrew Dunstan <andrew@dunslane.net>, Greg Stark <stark@mit.edu>, Jeremy Schneider <schneider@ardentperf.com>, Bruce Momjian <bruce@momjian.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, SATYANARAYANA NARLAPURAM <satyanarlapuram@gmail.com>, marvin_liang@qq.com, actyzhang@outlook.com
Date: 2022-03-16T14:26:59Z
Lists: pgsql-hackers
Greetings, * Bharath Rupireddy (bharath.rupireddyforpostgres@gmail.com) wrote: > On Tue, Mar 15, 2022 at 7:21 AM Bharath Rupireddy > <bharath.rupireddyforpostgres@gmail.com> wrote: > > > > On Mon, Mar 14, 2022 at 8:25 PM Stephen Frost <sfrost@snowman.net> wrote: > > > > > > > As this patch is currently written, pg_monitor has access these > > > > functions, though I don't think that's the right privilege level at > > > > least for pg_get_raw_wal_record(). > > > > > > Yeah, I agree that pg_monitor isn't the right thing for such a function > > > to be checking. > > > > On Thu, Mar 10, 2022 at 1:52 PM Jeff Davis <pgsql@j-davis.com> wrote: > > > > > > * pg_get_raw_wal_record() seems too powerful for pg_monitor. Maybe that > > > function should require pg_read_server_files? Or at least > > > pg_read_all_data? > > > > The v9 patch set posted at [1] grants execution on > > pg_get_raw_wal_record() to the pg_monitor role. > > > > pg_read_all_data may not be the right choice, but pg_read_server_files > > is as these functions do read the WAL files on the server. If okay, > > I'm happy to grant execution on pg_get_raw_wal_record() to the > > pg_read_server_files role. > > > > Thoughts? > > > > [1] https://www.postgresql.org/message-id/CALj2ACVRH-z8mZLyFkpLvY4qRhxQCqU_BLkFTtwt%2BTPZNhfEVg%40mail.gmail.com > > Attaching v10 patch set which allows pg_get_raw_wal_record to be > executed by either superuser or users with pg_read_server_files role, > no other change from v9 patch set. In a quick look, that seems reasonable to me. If folks want to give out access to this function individually they're also able to do so, which is good. Doesn't seem worthwhile to introduce a new predefined role for this one function. Thanks, Stephen
Commits
-
Doc build fix: remove tab from filelist.sgml.
- 8638c76cc9f4 15.0 landed
-
Add contrib/pg_walinspect.
- 2258e76f90bf 15.0 landed
-
Simplify SRFs using materialize mode in contrib/ modules
- 5b81703787bf 15.0 cited
-
Invent "trusted" extensions, and remove the pg_pltemplate catalog.
- 50fc694e4374 13.0 cited