From a0dab332a2e1961f45b38b23bd428859621e6f3c Mon Sep 17 00:00:00 2001
From: Tom Lane <tgl@sss.pgh.pa.us>
Date: Sat, 21 Jul 2007 22:12:04 +0000
Subject: [PATCH] Fix elog.c to avoid infinite recursion (leading to backend
crash) when log_min_error_statement is active and there is some problem in
logging the current query string; for example, that it's too long to include
in the log message without running out of memory. This problem has existed
since the log_min_error_statement feature was introduced. No doubt the
reason it wasn't detected long ago is that 8.2 is the first release that
defaults log_min_error_statement to less than PANIC level. Per report from
Bill Moran.
---
src/backend/utils/error/elog.c | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 11231c90d6d..3b86de353b5 100644
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -42,7 +42,7 @@
*
*
* IDENTIFICATION
- * $PostgreSQL: pgsql/src/backend/utils/error/elog.c,v 1.189 2007/07/19 21:58:12 tgl Exp $
+ * $PostgreSQL: pgsql/src/backend/utils/error/elog.c,v 1.190 2007/07/21 22:12:04 tgl Exp $
*
*-------------------------------------------------------------------------
*/
@@ -240,10 +240,15 @@ errstart(int elevel, const char *filename, int lineno,
/*
* If we recurse more than once, the problem might be something broken
- * in a context traceback routine. Abandon them too.
+ * in a context traceback routine. Abandon them too. We also
+ * abandon attempting to print the error statement (which, if long,
+ * could itself be the source of the recursive failure).
*/
if (recursion_depth > 2)
+ {
error_context_stack = NULL;
+ debug_query_string = NULL;
+ }
}
if (++errordata_stack_depth >= ERRORDATA_STACK_SIZE)
{
--
GitLab