Replace max_expr_depth parameter with a max_stack_depth parameter that

is measured in kilobytes and checked against actual physical execution
stack depth, as per my proposal of 30-Dec.  This gives us a fairly
bulletproof defense against crashing due to runaway recursive functions.

1 files changed, 21 insertions, 13 deletions

diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml
index da6d6a5fbaa..93902043e35 100644
--- a/doc/src/sgml/runtime.sgml
+++ b/doc/src/sgml/runtime.sgml
@@ -1,5 +1,5 @@
 <!--
-$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.253 2004/03/24 03:48:41 neilc Exp $
+$PostgreSQL: pgsql/doc/src/sgml/runtime.sgml,v 1.254 2004/03/24 22:40:28 tgl Exp $
 -->
 
 <Chapter Id="runtime">
@@ -889,6 +889,26 @@ SET ENABLE_SEQSCAN TO OFF;
       </listitem>
      </varlistentry>
 
+     <varlistentry id="guc-max-stack-depth" xreflabel="max_stack_depth">
+      <term><varname>max_stack_depth</varname> (<type>integer</type>)</term>
+      <listitem>
+       <para>
+        Specifies the maximum safe depth of the server's execution stack.
+        The ideal setting for this parameter is the actual stack size limit
+        enforced by the kernel (as set by <literal>ulimit -s</> or local
+        equivalent), less a safety margin of a megabyte or so.  The safety
+        margin is needed because the stack depth is not checked in every
+        routine in the server, but only in key potentially-recursive routines
+        such as expression evaluation.  Setting the parameter higher than
+        the actual kernel limit will mean that a runaway recursive function
+        can crash an individual backend process.  The default setting is
+        2048 KB (two megabytes), which is conservatively small and unlikely
+        to risk crashes.  However, it may be too small to allow execution
+        of complex functions.
+       </para>
+      </listitem>
+     </varlistentry>
+
      </variablelist>
      </sect3>
      <sect3 id="runtime-config-resource-fsm">
@@ -2573,18 +2593,6 @@ dynamic_library_path = '/usr/local/lib/postgresql:/home/my_project/lib:$libdir'
       </listitem>
      </varlistentry>
 
-     <varlistentry id="guc-max-expr-depth" xreflabel="max_expr_depth">
-      <term><varname>max_expr_depth</varname> (<type>integer</type>)</term>
-      <listitem>
-       <para>
-        Sets the maximum expression nesting depth of the parser. The
-        default value of 10000 is high enough for any normal query,
-        but you can raise it if needed. (But if you raise it too high,
-        you run the risk of server crashes due to stack overflow.)
-       </para>
-      </listitem>
-     </varlistentry>
-
      </variablelist>
     </sect3>
    </sect2>