pg.ddx.io  pgsql-hackers@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig.ringer@enterprisedb.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: vignesh C <vignesh21@gmail.com>
Cc: Andres Freund <andres@anarazel.de>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Printing backtrace of postgres processes
Date: Wed, 20 Jan 2021 20:56:49 -0500
Message-ID: <799340.1611194209@sss.pgh.pa.us> (raw)
In-Reply-To: <CAGRY4nxmyaGs4-o4JSMwsUmqe++y-9zPEmJTeRn5ZOOdNzxi5w@mail.gmail.com>
References: <CALDaNm3ZzmFS-=r7oDUzj7y7BgQv+N06Kqyft6C3xZDoKnk_6w@mail.gmail.com>
	<1778088.1606026308@sss.pgh.pa.us>
	<20201201032649.aekv5b5dicvmovf4@alap3.anarazel.de>
	<1361750.1606795285@sss.pgh.pa.us>
	<CALDaNm0pUzawA96LjKohn8eF2BSxkZMRvO70M1-bcbhGvznQuA@mail.gmail.com>
	<CALDaNm0DN3TJsSP6PT=maw1KLKvhHwFfOhokUGKprLaiZrU-mw@mail.gmail.com>
	<55526d79-247d-83a1-0961-7d42e0db1870@enterprisedb.com>
	<20210115201011.noomcygirzge43ir@alap3.anarazel.de>
	<CALDaNm2wjFrizmy+yvNbedYKxorZBcGYXNMaoPC6zwSaLsmwLg@mail.gmail.com>
	<3537.1610828491@sss.pgh.pa.us>
	<CA+TgmobpOhhm0poFsShjoM=sOxkbzc78f2TdNyZpGz4GSJHh6g@mail.gmail.com>
	<492025.1611078655@sss.pgh.pa.us>
	<CA+TgmoZ8XeQVCCqfq826kAr804a1ZnYy46FnQB9r2n_iOofh8Q@mail.gmail.com>
	<523589.1611091371@sss.pgh.pa.us>
	<CAGRY4nxmyaGs4-o4JSMwsUmqe++y-9zPEmJTeRn5ZOOdNzxi5w@mail.gmail.com>

Craig Ringer <craig.ringer@enterprisedb.com> writes:
> On Wed, 20 Jan 2021 at 05:23, Tom Lane <tgl@sss.pgh.pa.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.

			regards, tom lane





view thread (135+ messages)  latest in thread

Message-ID: <799340.1611194209@sss.pgh.pa.us>
Permalink:  ../799340.1611194209@sss.pgh.pa.us/
Also on:    postgresql.org/message-id/799340.1611194209@sss.pgh.pa.us

 · 

reply
Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-hackers@postgresql.org
  Cc: tgl@sss.pgh.pa.us, craig.ringer@enterprisedb.com, robertmhaas@gmail.com, vignesh21@gmail.com, andres@anarazel.de, peter.eisentraut@enterprisedb.com, pgsql-hackers@lists.postgresql.org
  Subject: Re: Printing backtrace of postgres processes
  In-Reply-To: <799340.1611194209@sss.pgh.pa.us>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox