From: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)oss(dot)nttdata(dot)com>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: maximum number of backtrace frames logged by backtrace_functions |
Date: | 2022-02-03 09:30:00 |
Message-ID: | b219d7c9-fb66-c762-ce90-ef20c0667a02@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On 03.02.22 06:33, Fujii Masao wrote:
> I encountered the "more than 100 backtrace frames" case when
> investigating the bug of pg_log_query_plan() patch [1]. Since the
> function that the patch added can be called repeatedly during call to
> that function, the backtrace became larger than 100. I think this is not
> general case, so basically 100 sounds enough limit size to me.
>
> OTOH I think it's helpful if the limit is documented when I occasionally
> encounter the case and want to understand why all backtrace frames are
> not logged.
How about we issue a message when the backtrace is cut off. Then it's
immediately visible to the user, instead of hidden away somewhere in the
documentation. Something like this (untested):
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 7402696986..3777dff030 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -967,6 +967,8 @@ set_backtrace(ErrorData *edata, int num_skip)
for (int i = num_skip; i < nframes; i++)
appendStringInfo(&errtrace, "\n%s", strfrms[i]);
free(strfrms);
+ if (nframes >= lengthof(buf))
+ appendStringInfo(&errtrace, "\n(backtrace limited to %zu frames)",
lengthof(buf));
}
#else
appendStringInfoString(&errtrace,
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2022-02-03 14:48:16 | Re: maximum number of backtrace frames logged by backtrace_functions |
Previous Message | Fujii Masao | 2022-02-03 05:33:12 | Re: maximum number of backtrace frames logged by backtrace_functions |