Re: Printing backtrace of postgres processes

On Thu, 21 Jan 2021 at 09:56, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Craig Ringer <craig(dot)ringer(at)enterprisedb(dot)com> writes:
> > On Wed, 20 Jan 2021 at 05:23, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> BTW, it also looks like the patch is doing nothing to prevent the
> >> backtrace from being sent to the connected client.
>
> > I don't see a good reason to send a bt to a client. Even though these
> > backtraces won't be analysing debuginfo and populating args, locals, etc,
> > it should still just go to the server log.
>
> Yeah. That's easier than I was thinking, we just need to
> s/LOG/LOG_SERVER_ONLY/.
>
> >> Maybe, given all of these things, we should forget using elog at
> >> all and just emit the trace with fprintf(stderr).
>
> > That causes quite a lot of pain with MemoryContextStats() already
>
> True. Given the changes discussed in the last couple messages, I don't
> see any really killer reasons why we can't ship the trace through elog.
> We can always try that first, and back off to fprintf if we do find
> reasons why it's too unstable.
>

Yep, works for me.

Thanks for being open to considering this.

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.