There's usually no
         reason to change this unless you are building for a Windows
         environment, in which case it must be set to upper case
         <literal>POSTGRES</literal>.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="configure-option-with-segsize">
       <term><option>--with-segsize=<replaceable>SEGSIZE</replaceable></option></term>
       <listitem>
        <para>
         Set the <firstterm>segment size</firstterm>, in gigabytes.  Large tables are
         divided into multiple operating-system files, each of size equal
         to the segment size.  This avoids problems with file size limits
         that exist on many platforms.  The default segment size, 1 gigabyte,
         is safe on all supported platforms.  If your operating system has
         <quote>largefile</quote> support (which most do, nowadays), you can use
         a larger segment size.  This can be helpful to reduce the number of
         file descriptors consumed when working with very large tables.
         But be careful not to select a value larger than is supported
         by your platform and the file systems you intend to use.  Other
         tools you might wish to use, such as <application>tar</application>, could
         also set limits on the usable file size.
         It is recommended, though not absolutely required, that this value
         be a power of 2.
         Note that changing this value breaks on-disk database compatibility,
         meaning you cannot use <command>pg_upgrade</command> to upgrade to
         a build with a different segment size.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="configure-option-with-blocksize">
       <term><option>--with-blocksize=<replaceable>BLOCKSIZE</replaceable></option></term>
       <listitem>
        <para>
         Set the <firstterm>block size</firstterm>, in kilobytes.  This is the unit
         of storage and I/O within tables.  The default, 8 kilobytes,
         is suitable for most situations; but other values may be useful
         in special cases.
         The value must be a power of 2 between 1 and 32 (kilobytes).
         Note that changing this value breaks on-disk database compatibility,
         meaning you cannot use <command>pg_upgrade</command> to upgrade to
         a build with a different block size.
        </para>
       </listitem>
      </varlistentry>

      <varlistentry id="configure-option-with-wal-blocksize">
       <term><option>--with-wal-blocksize=<replaceable>BLOCKSIZE</replaceable></option></term>
       <listitem>
        <para>
         Set the <firstterm>WAL block size</firstterm>, in kilobytes.  This is the unit
         of storage and I/O within the WAL log.  The default, 8 kilobytes,
         is suitable for most situations; but other values may be useful
         in special cases.
         The value must be a power of 2 between 1 and 64 (kilobytes).
         Note that changing this value breaks on-disk database compatibility,
         meaning you cannot use <command>pg_upgrade</command> to upgrade to
         a build with a different WAL block size.
        </para>
       </listitem>
      </varlistentry>

     </variablelist>

   </sect3>

   <sect3 id="configure-options-devel">
    <title>Developer Options</title>

    <para>
     Most of the options in this section are only of interest for
     developing or debugging <productname>PostgreSQL</productname>.
     They are not recommended for production builds, except
     for <option>--enable-debug</option>, which can be useful to enable
     detailed bug reports in the unlucky event that you encounter a bug.
     On platforms supporting DTrace, <option>--enable-dtrace</option>
     may also be reasonable to use in production.
    </para>

    <para>
     When building an installation that will be used to develop code inside
     the server, it is recommended to use at least the
     options <option>--enable-debug</option>