Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit a0dab33

Browse files
committed
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.
1 parent ddb93ca commit a0dab33

File tree

1 file changed

+7
-2
lines changed

1 file changed

+7
-2
lines changed

src/backend/utils/error/elog.c

+7-2
Original file line numberDiff line numberDiff line change
@@ -42,7 +42,7 @@
4242
*
4343
*
4444
* IDENTIFICATION
45-
* $PostgreSQL: pgsql/src/backend/utils/error/elog.c,v 1.189 2007/07/19 21:58:12 tgl Exp $
45+
* $PostgreSQL: pgsql/src/backend/utils/error/elog.c,v 1.190 2007/07/21 22:12:04 tgl Exp $
4646
*
4747
*-------------------------------------------------------------------------
4848
*/
@@ -240,10 +240,15 @@ errstart(int elevel, const char *filename, int lineno,
240240

241241
/*
242242
* If we recurse more than once, the problem might be something broken
243-
* in a context traceback routine. Abandon them too.
243+
* in a context traceback routine. Abandon them too. We also
244+
* abandon attempting to print the error statement (which, if long,
245+
* could itself be the source of the recursive failure).
244246
*/
245247
if (recursion_depth > 2)
248+
{
246249
error_context_stack = NULL;
250+
debug_query_string = NULL;
251+
}
247252
}
248253
if (++errordata_stack_depth >= ERRORDATA_STACK_SIZE)
249254
{

0 commit comments

Comments
 (0)