Horton

Re: Printing backtrace of postgres processes

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, vignesh C <vignesh21@gmail.com>, Andres Freund <andres@anarazel.de>, Peter Eisentraut <peter.eisentraut@enterprisedb.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2021-01-25T17:05:24Z
Lists: pgsql-hackers 
On Wed, Jan 20, 2021 at 9:24 PM Craig Ringer
<craig.ringer@enterprisedb.com> wrote:
> I know lots of this stuff can seem like a pointless sidetrack because the utility of it is not obvious on dev systems or when you're doing your own hands-on expert support on systems you own and operate yourself. These sorts of things really only start to make sense when you're touching many different postgres systems "in the wild" - such as commercial support services, helping people on -general, -bugs or stackoverflow, etc.
>
> I really appreciate your help with it.

Big +1 for all that from me, too.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

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