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
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 |