Re: maximum number of backtrace frames logged by backtrace_functions
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,
Re: maximum number of backtrace frames logged by backtrace_functions
Peter Eisentraut writes: > 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): +1 for idea (I didn't test it either). Is "nframes" useful enough to include in the report? regards, tom lane
Re: maximum number of backtrace frames logged by backtrace_functions
On 2022/02/03 23:48, Tom Lane wrote: Peter Eisentraut writes: 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): +1 for idea (I didn't test it either). +1. I made this change to the patch and confirmed that it worked fine. For the record, I tested that by setting backtrace_functions to 'pg_wal_replay_pause' and executing it. This function will report an error when it's called not during recovery. In the test, "SELECT pg_wal_replay_pause()" caused backtrace but "backtrace limited to %zu frames" message was not output because the number of backtrace frames was less than 100. Then I created the function "foo" as follows and executed "SELECT foo(0)" to generate more than 100 backtrace frames. In this case "backtrace limited to %zu frames" message was successfully output. CREATE FUNCTION foo (x int) RETURNS void AS $$ BEGIN IF x = 10 THEN PERFORM pg_wal_replay_pause(); ELSE PERFORM foo(x + 1); END IF; END; $$ LANGUAGE plpgsql; Is "nframes" useful enough to include in the report? Probably No because "nframes" is equal to "lengthof(buf)" in the case where more than 100 frames are generated. Regards, -- Fujii Masao Advanced Computing Technology Center Research and Development Headquarters NTT DATA CORPORATIONdiff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c index 7402696986..9933386959 100644 --- a/src/backend/utils/error/elog.c +++ b/src/backend/utils/error/elog.c @@ -966,6 +966,9 @@ set_backtrace(ErrorData *edata, int num_skip) for (int i = num_skip; i < nframes; i++) appendStringInfo(&errtrace, "\n%s", strfrms[i]); + if (nframes >= lengthof(buf)) + appendStringInfo(&errtrace, "\n(backtrace limited to %zu frames)", +lengthof(buf)); free(strfrms); } #else
