Re: Printing backtrace of postgres processes
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: 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-19T17:30:52Z
Lists: pgsql-hackers
On Sat, Jan 16, 2021 at 3:21 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I'd argue that backtraces for those processes aren't really essential, > and indeed that trying to make the syslogger report its own backtrace > is damn dangerous. I agree. Ideally I'd like to be able to use the same mechanism everywhere and include those processes too, but surely regular backends and parallel workers are going to be the things that come up most often. > (Personally, I think this whole patch fails the safety-vs-usefulness > tradeoff, but I expect I'll get shouted down.) You and I are frequently on opposite sides of these kinds of questions, but I think this is a closer call than many cases. I'm convinced that it's useful, but I'm not sure whether it's safe. On the usefulness side, backtraces are often the only way to troubleshoot problems that occur on production systems. I wish we had better logging and tracing tools instead of having to ask for this sort of thing, but we don't. EDB support today frequently asks customers to attach gdb and take a backtrace that way, and that has risks which this implementation does not: for example, suppose you were unlucky enough to attach during a spinlock protected critical section, and suppose you didn't continue the stopped process before the 60 second timeout expired and some other process caused a PANIC. Even if this implementation were to end up emitting a backtrace with a spinlock held, it would remove the risk of leaving the process stopped while holding a critical lock, and would in that sense be safer. However, as soon as you make something like this accessible via an SQL callable function, some people are going to start spamming it. And, as soon as they do that, any risks inherent in the implementation are multiplied. If it carries an 0.01% chance of crashing the system, we'll have people taking production systems down with this all the time. At that point I wouldn't want the feature, even if the gdb approach had the same risk (which I don't think it does). What do you see as the main safety risks here? -- Robert Haas EDB: http://www.enterprisedb.com
Commits
-
Perform apply of large transactions by parallel workers.
- 216a784829c2 16.0 cited
-
Enhance pg_log_backend_memory_contexts() for auxiliary processes.
- 790fbda90209 15.0 cited
-
Allow GRANT on pg_log_backend_memory_contexts().
- f0b051e322d5 15.0 cited
-
Move Perl test modules to a better namespace
- b3b4d8e68ae8 15.0 cited
-
Unify PostgresNode's new() and get_new_node() methods
- 201a76183e20 15.0 cited
-
Add backtrace support for error reporting
- 71a8a4f6e365 13.0 cited