needed.  That setting is appropriate for a command that requires a
        TTY for prompting, which might not be available when the server is
        running.  Setting this parameter to on might be appropriate if the
        passphrase is obtained from a file, for example.
       </para>
       <para>
        This parameter can only be set in the <filename>postgresql.conf</filename>
        file or on the server command line.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
    </sect2>
   </sect1>

   <sect1 id="runtime-config-resource">
    <title>Resource Consumption</title>

    <sect2 id="runtime-config-resource-memory">
     <title>Memory</title>

     <variablelist>
     <varlistentry id="guc-shared-buffers" xreflabel="shared_buffers">
      <term><varname>shared_buffers</varname> (<type>integer</type>)
      <indexterm>
       <primary><varname>shared_buffers</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Sets the amount of memory the database server uses for shared
        memory buffers.  The default is typically 128 megabytes
        (<literal>128MB</literal>), but might be less if your kernel settings will
        not support it (as determined during <application>initdb</application>).
        This setting must be at least 128 kilobytes.  However,
        settings significantly higher than the minimum are usually needed
        for good performance.
        If this value is specified without units, it is taken as blocks,
        that is <symbol>BLCKSZ</symbol> bytes, typically 8kB.
        (Non-default values of <symbol>BLCKSZ</symbol> change the minimum
        value.)
        This parameter can only be set at server start.
       </para>

       <para>
        If you have a dedicated database server with 1GB or more of RAM, a
        reasonable starting value for <varname>shared_buffers</varname> is 25%
        of the memory in your system.  There are some workloads where even
        larger settings for <varname>shared_buffers</varname> are effective, but
        because <productname>PostgreSQL</productname> also relies on the
        operating system cache, it is unlikely that an allocation of more than
        40% of RAM to <varname>shared_buffers</varname> will work better than a
        smaller amount.  Larger settings for <varname>shared_buffers</varname>
        usually require a corresponding increase in
        <varname>max_wal_size</varname>, in order to spread out the
        process of writing large quantities of new or changed data over a
        longer period of time.
       </para>

       <para>
        On systems with less than 1GB of RAM, a smaller percentage of RAM is
        appropriate, so as to leave adequate space for the operating system.
       </para>

      </listitem>
     </varlistentry>

     <varlistentry id="guc-huge-pages" xreflabel="huge_pages">
      <term><varname>huge_pages</varname> (<type>enum</type>)
      <indexterm>
       <primary><varname>huge_pages</varname> configuration parameter</primary>
      </indexterm>
      </term>
      <listitem>
       <para>
        Controls whether huge pages are requested for the main shared memory
        area. Valid values are <literal>try</literal> (the default),
        <literal>on</literal>, and <literal>off</literal>.  With
        <varname>huge_pages</varname> set to <literal>try</literal>, the
        server will try to request huge pages, but fall back to the default if
        that fails. With <literal>on</literal>, failure to request huge pages
        will prevent the server from starting up. With <literal>off</literal>,
        huge pages will not be requested. The actual state of huge pages is
        indicated by the server variable
        <xref linkend="guc-huge-pages-status"/>.
       </para>

       <para>
        At present, this setting is supported only on Linux and Windows. The
        setting is ignored on other systems when