Re: maximum number of backtrace frames logged by backtrace_functions

From: Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>
To: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-docs(at)lists(dot)postgresql(dot)org
Subject: Re: maximum number of backtrace frames logged by backtrace_functions
Date: 2022-02-18 08:24:58
Message-ID: 7fce4874-1433-42e2-6649-e2c57ce50d4e@oss.nttdata.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On 2022/02/18 16:07, Peter Eisentraut wrote:
> On 07.02.22 17:42, Fujii Masao wrote:
>> On 2022/02/08 1:12, Peter Eisentraut wrote:
>>> This change looks good to me.  There is also backtrace code in assert.c that might want the same treatment.
>>
>> Yeah, that's good idea! The attached patch also adds the same treatment into assert.c.
>
> I don't know if using write_stderr() is the right thing here.  Since backtrace_symbols_fd() writes directly to stderr in any case, the whole Windows-specific eventlog dance in write_stderr() wouldn't make sense even if this feature supported Windows.  So I'd just do a straight fprintf(stderr) there.

Yeah, maybe.

Or even backtrace should be logged by write_stderr() so that it's written to eventlog if necessary? I just wonder why backtrace_symbols_fd() is used only in ExceptionalCondition().

Regards,

--
Fujii Masao
Advanced Computing Technology Center
Research and Development Headquarters
NTT DATA CORPORATION

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Peter Eisentraut 2022-02-18 10:59:17 Re: maximum number of backtrace frames logged by backtrace_functions
Previous Message Peter Eisentraut 2022-02-18 07:07:48 Re: maximum number of backtrace frames logged by backtrace_functions