Horton

Re: Printing backtrace of postgres processes

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Andres Freund <andres@anarazel.de>, Craig Ringer <craig.ringer@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-06T18:56:09Z
Lists: pgsql-hackers 
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?

			regards, tom lane

Commits

  1. Perform apply of large transactions by parallel workers.

  2. Enhance pg_log_backend_memory_contexts() for auxiliary processes.

  3. Allow GRANT on pg_log_backend_memory_contexts().

  4. Move Perl test modules to a better namespace

  5. Unify PostgresNode's new() and get_new_node() methods

  6. Add backtrace support for error reporting