Clear error_context_stack and debug_query_string at the beginning of proc_exit,

so that we won't try to attach any context printouts to messages that get
emitted while exiting.  Per report from Dennis Koegel, the context functions
won't necessarily work after we've started shutting down the backend, and it
seems possible that debug_query_string could be pointing at freed storage
as well.  The context information doesn't seem particularly relevant to
such messages anyway, so there's little lost by suppressing it.

Back-patch to all supported branches.  I can only demonstrate a crash with
log_disconnections messages back to 8.1, but the risk seems real in 8.0 and
before anyway.

src/backend/storage/ipc/ipc.c

@@ -13,7 +13,7 @@
  *
  *
  * IDENTIFICATION
- *	  $PostgreSQL: pgsql/src/backend/storage/ipc/ipc.c,v 1.100.2.1 2008/04/16 23:59:51 tgl Exp $
+ *	  $PostgreSQL: pgsql/src/backend/storage/ipc/ipc.c,v 1.100.2.2 2010/03/20 00:58:21 tgl Exp $
  *
  *-------------------------------------------------------------------------
  */
@@ -28,6 +28,7 @@
 #include "postmaster/autovacuum.h"
 #endif
 #include "storage/ipc.h"
+#include "tcop/tcopprot.h"
 
 
 /*
@@ -95,6 +96,19 @@ proc_exit(int code)
 	InterruptHoldoffCount = 1;
 	CritSectionCount = 0;
 
+	/*
+	 * Also clear the error context stack, to prevent error callbacks
+	 * from being invoked by any elog/ereport calls made during proc_exit.
+	 * Whatever context they might want to offer is probably not relevant,
+	 * and in any case they are likely to fail outright after we've done
+	 * things like aborting any open transaction.  (In normal exit scenarios
+	 * the context stack should be empty anyway, but it might not be in the
+	 * case of elog(FATAL) for example.)
+	 */
+	error_context_stack = NULL;
+	/* For the same reason, reset debug_query_string before it's clobbered */
+	debug_query_string = NULL;
+
 	elog(DEBUG3, "proc_exit(%d)", code);
 
 	/* do our shared memory exits first */