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.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="configure-blocksize-meson">
      <term><option>-Dblocksize=<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).
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="configure-wal-blocksize-meson">
      <term><option>-Dwal_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).
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </sect3>

   <sect3 id="meson-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>--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>-Ddtrace</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 <option>--buildtype=debug</option>
     and <option>-Dcassert</option> options.
    </para>

    <variablelist>
     <varlistentry id="configure-buildtype-meson">
      <term><option>--buildtype=<replaceable>BUILDTYPE</replaceable></option></term>
      <listitem>
       <para>
        This option can be used to specify the buildtype to use; defaults to
        <option>debugoptimized</option>.  If you'd like finer control on the debug
        symbols and optimization levels than what this option provides, you
        can refer to the <option>--debug</option> and
        <option>--optimization</option> flags.
       </para>

       <para>
        The following build types are generally used: <option>plain</option>,
        <option>debug</option>, <option>debugoptimized</option> and
        <option>release</option>.  More information about them can be found in
        the <ulink
        url="https://mesonbuild.com/Running-Meson.html#configuring-the-build-directory">Meson
        documentation</ulink>.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="configure-debug-meson">
      <term><option>--debug</option></term>
      <listitem>
       <para>
        Compiles all programs and libraries with debugging symbols.  This
        means that you can run the programs in a debugger to analyze
        problems. This enlarges the size of the installed executables
        considerably, and on non-GCC compilers it usually also disables
        compiler