executing the
       <link linkend="sql-checkpoint"><command>CHECKPOINT</command></link> command.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-create-subscription" xreflabel="pg_create_subscription">
     <term><varname>pg_create_subscription</varname></term>
     <listitem>
      <para>
       <literal>pg_create_subscription</literal> allows users with
       <literal>CREATE</literal> permission on the database to issue
       <link linkend="sql-createsubscription"><command>CREATE SUBSCRIPTION</command></link>.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-database-owner" xreflabel="pg_database_owner">
     <term><varname>pg_database_owner</varname></term>
     <listitem>
      <para>
       <literal>pg_database_owner</literal> always has exactly one implicit
       member: the current database owner.  It cannot be granted membership in
       any role, and no role can be granted membership in
       <literal>pg_database_owner</literal>.  However, like any other role, it
       can own objects and receive grants of access privileges.  Consequently,
       once <literal>pg_database_owner</literal> has rights within a template
       database, each owner of a database instantiated from that template will
       possess those rights.  Initially, this role owns the
       <literal>public</literal> schema, so each database owner governs local
       use of that schema.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-maintain" xreflabel="pg_maintain">
     <term><varname>pg_maintain</varname></term>
     <listitem>
      <para>
       <literal>pg_maintain</literal> allows executing
       <link linkend="sql-vacuum"><command>VACUUM</command></link>,
       <link linkend="sql-analyze"><command>ANALYZE</command></link>,
       <link linkend="sql-cluster"><command>CLUSTER</command></link>,
       <link linkend="sql-refreshmaterializedview"><command>REFRESH MATERIALIZED VIEW</command></link>,
       <link linkend="sql-reindex"><command>REINDEX</command></link>,
       and <link linkend="sql-lock"><command>LOCK TABLE</command></link> on all
       relations, as if having <literal>MAINTAIN</literal> rights on those
       objects.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="predefined-role-pg-monitor" xreflabel="pg_monitor">
     <term><varname>pg_monitor</varname></term>
     <term><varname>pg_read_all_settings</varname></term>
     <term><varname>pg_read_all_stats</varname></term>
     <term><varname>pg_stat_scan_tables</varname></term>
     <listitem>
      <para>
       These roles are intended to allow administrators to easily configure a
       role for the purpose of monitoring the database server.  They grant a
       set of common privileges allowing the role to read various useful
       configuration settings, statistics, and other system information
       normally restricted to superusers.
      </para>
      <para>
       <literal>pg_monitor</literal> allows reading/executing various
       monitoring views and functions.  This role is a member of
       <literal>pg_read_all_settings</literal>,
       <literal>pg_read_all_stats</literal> and
       <literal>pg_stat_scan_tables</literal>.
      </para>
      <para>
       <literal>pg_read_all_settings</literal> allows reading all configuration
       variables, even those normally visible only to superusers.
      </para>
      <para>
       <literal>pg_read_all_stats</literal> allows reading all pg_stat_* views
       and use various statistics related extensions, even those normally
       visible only to superusers.
      </para>
      <para>
       <literal>pg_stat_scan_tables</literal> allows executing monitoring
       functions that may take <literal>ACCESS SHARE</literal> locks on tables,
       potentially for a long time (e.g., <function>pgrowlocks(text)</function>
       in the <xref linkend="pgrowlocks"/>