Re: Printing backtrace of postgres processes

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: Printing backtrace of postgres processes
Дата
Msg-id CAGRY4ny3xVQ+sZcizRayvcvXD-u_922fb+vj_o8s5g9++K3UNg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Printing backtrace of postgres processes  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Printing backtrace of postgres processes  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Thu, 21 Jan 2021 at 09:56, Tom Lane <tgl@sss.pgh.pa.us> wrote:
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.

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.

В списке pgsql-hackers по дате отправления:

Предыдущее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: POC: postgres_fdw insert batching
Следующее
От: Zhihong Yu
Дата:
Сообщение: Re: Parallel INSERT (INTO ... SELECT ...)