Re: Printing backtrace of postgres processes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Printing backtrace of postgres processes
Date
Msg-id 799340.1611194209@sss.pgh.pa.us
Whole thread Raw
In response to Re: Printing backtrace of postgres processes  (Craig Ringer <craig.ringer@enterprisedb.com>)
Responses Re: Printing backtrace of postgres processes  (Craig Ringer <craig.ringer@enterprisedb.com>)
Re: Printing backtrace of postgres processes  (vignesh C <vignesh21@gmail.com>)
List pgsql-hackers
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



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: POC: postgres_fdw insert batching
Next
From: "tsunakawa.takay@fujitsu.com"
Date:
Subject: RE: POC: postgres_fdw insert batching