postgres.git / summary / log / commit / refs

commit    987b0664fbab1e7b5e88484ed3b8b200d2a27cd1
Author:   Tom Lane <tgl@sss.pgh.pa.us>
Date:     Sat Jul 21 22:12:17 2007 +0000
First released in: 8.3.0, 7.3.20, 7.4.18, 8.0.14, 8.1.10, 8.2.5

    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 5e1a807fd40..7446f37ffda 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.167.2.4 2007/07/19 19:14:54 adunstan Exp $
+ *	  $PostgreSQL: pgsql/src/backend/utils/error/elog.c,v 1.167.2.5 2007/07/21 22:12:17 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -260,10 +260,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)
 	{


[parent: 6d8afdee000f]