<primary><varname>transaction_buffers</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the amount of shared memory to use to cache the contents
        of <literal>pg_xact</literal> (see
        <xref linkend="pgdata-contents-table"/>).
        If this value is specified without units, it is taken as blocks,
        that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
        The default value is <literal>0</literal>, which requests
        <varname>shared_buffers</varname>/512 up to 1024 blocks,
        but not fewer than 16 blocks.
        This parameter can only be set at server start.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-max-stack-depth" xreflabel="max_stack_depth">
      <term><varname>max_stack_depth</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>max_stack_depth</varname> configuration parameter</primary>
      </indexterm>
      </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</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.
        If this value is specified without units, it is taken as kilobytes.
        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 and users with the appropriate <literal>SET</literal>
        privilege can change this setting.
       </para>

       <para>
        Setting <varname>max_stack_depth</varname> higher than
        the actual kernel limit will mean that a runaway recursive function
        can crash an individual backend process.  On platforms where
        <productname>PostgreSQL</productname> can determine the kernel limit,
        the server will not allow this variable to be set to an unsafe
        value.  However, not all platforms provide the information,
        so caution is recommended in selecting a value.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-shared-memory-type" xreflabel="shared_memory_type">
      <term><varname>shared_memory_type</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>shared_memory_type</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Specifies the shared memory implementation that the server
        should use for the main shared memory region that holds
        <productname>PostgreSQL</productname>'s shared buffers and other
        shared data.  Possible values are <literal>mmap</literal> (for
        anonymous shared memory allocated using <function>mmap</function>),
        <literal>sysv</literal> (for System V shared memory allocated via
        <function>shmget</function>) and <literal>windows</literal> (for Windows
        shared memory).  Not all values are supported on all platforms; the
        first supported option is the default for that platform.  The use of
        the <literal>sysv</literal> option, which is not the default on any
        platform, is generally discouraged because it typically requires
        non-default kernel settings to allow for large allocations (see <xref
        linkend="sysvipc"/>).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="guc-dynamic-shared-memory-type" xreflabel="dynamic_shared_memory_type">
      <term><varname>dynamic_shared_memory_type</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>dynamic_shared_memory_type</varname>