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: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, vignesh C <vignesh21@gmail.com>, Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>, Craig Ringer <craig.ringer@enterprisedb.com>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-05-06T19:31:02Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On 2021-05-06 14:56:09 -0400, Tom Lane wrote:
>> 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.

I'd probably vote for pg_read_all_data, considering that much of
the concern about this has to do with the possibility of exposure
of sensitive data.  I'm not quite sure what the security expectations
are for pg_monitor.

			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