Re: Printing backtrace of postgres processes

Hi,

On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Wed, Feb 3, 2021 at 2:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> >> TBH, I'm leaning to the position that this should be superuser
> >> only.
> 
> > I agree that ordinary users shouldn't be able to trigger it, but I
> > think it should be restricted to some predefined role, new or
> > existing, rather than to superuser. I see no reason not to let
> > individual users decide what risks they want to take.
> 
> If we think it's worth having a predefined role for, OK.  However,
> I don't like the future I see us heading towards where there are
> hundreds of random predefined roles.  Is there an existing role
> that it'd be reasonable to attach this ability to?

It does seem like it'd be good to group it in with something
else. There's nothing fitting 100% though.

postgres[1475723][1]=# SELECT rolname FROM pg_roles WHERE rolname LIKE 'pg_%' ORDER BY rolname;
┌───────────────────────────┐
│          rolname          │
├───────────────────────────┤
│ pg_database_owner         │
│ pg_execute_server_program │
│ pg_monitor                │
│ pg_read_all_data          │
│ pg_read_all_settings      │
│ pg_read_all_stats         │
│ pg_read_server_files      │
│ pg_signal_backend         │
│ pg_stat_scan_tables       │
│ pg_write_all_data         │
│ pg_write_server_files     │
└───────────────────────────┘
(11 rows)

We could fit it into pg_monitor, but it's probably a bit more impactful
than most things in there? But I'd go for it anyway, I think.

Greetings,

Andres Freund