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.

diff --git a/src/backend/utils/error/elog.c b/src/backend/utils/error/elog.c
index 2186920d7e3e22ef5c38a6d77b17b7cc9cd02857..45c07178c13cbbf02b29a361d4b1fca1f27195a3 100644 (file)
--- a/src/backend/utils/error/elog.c
+++ b/src/backend/utils/error/elog.c
@@ -37,7 +37,7 @@
  *
  *
  * IDENTIFICATION
- *       $Header: /cvsroot/pgsql/src/backend/utils/error/elog.c,v 1.125.2.2 2005/10/20 01:31:50 tgl Exp $
+ *       $Header: /cvsroot/pgsql/src/backend/utils/error/elog.c,v 1.125.2.3 2007/07/21 22:12:32 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -254,11 +254,16 @@ errstart(int elevel, const char *filename, int lineno,
                MemoryContextReset(ErrorContext);
 
                /*
-                * If we recurse more than once, the problem might be something
-                * broken in a context traceback routine.  Abandon them too.
+                * If we recurse more than once, the problem might be something broken
+                * 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)
        {