On 2022/02/03 23:48, Tom Lane wrote:
Peter Eisentraut <peter.eisentr...@enterprisedb.com> 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 CORPORATION
diff --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
