On 12/8/18, Tom Lane <t...@sss.pgh.pa.us> wrote:
> John Naylor <jcnay...@gmail.com> writes:
>> In confg.sgml, in the section about max_stack_depth, there's this
>> sentence:
>> "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."
>
>> Since the change in expression evaluation in v10, there's probably a
>> better example of recursive routines, but I'm not sure what that would
>> be.
>
> We could say "expression compilation" and it'd still be valid.  Or just
> drop the last four words altogether.  I don't think we want to expend the
> verbiage to be more precise here, since it's only a tangential point.

I'm inclined to agree. If you like, here's a patch to leave out the example.

-John Naylor
diff --git a/doc/src/sgml/config.sgml b/doc/src/sgml/config.sgml
index fc4f17be41..4a7121a51f 100644
--- a/doc/src/sgml/config.sgml
+++ b/doc/src/sgml/config.sgml
@@ -1675,12 +1675,11 @@ include_dir 'conf.d'
         enforced by the kernel (as set by <literal>ulimit -s</literal> 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.  The default setting is two
-        megabytes (<literal>2MB</literal>), which is conservatively small and
-        unlikely to risk crashes.  However, it might be too small to allow
-        execution of complex functions.  Only superusers can change this
-        setting.
+        routine in the server, but only in key potentially-recursive routines.
+        The default setting is two megabytes (<literal>2MB</literal>), which
+        is conservatively small and unlikely to risk crashes.  However,
+        it might be too small to allow execution of complex functions.
+        Only superusers can change this setting.
        </para>
 
        <para>

Reply via email to