Roles
=====

Configuring and managing PGD doesn’t require superuser access. We
recommend that you don’t use superuser access. Instead, the privileges
required to administer PGD are split across the following predefined
roles.

.. csv-table::
  :header: Role,Description
  :widths: 10,30
  :align: left
  :class: longtable

  :ref:`Eager <PGD predefined roles>` ,"The highest-privileged role, having access to all PGD tables and functions."
  :ref:`Eager <PGD predefined roles>` ,"The role having read-only access to the tables, views, and functions, sufficient to understand the state of PGD."
  :ref:`Eager <PGD predefined roles>` ,"Includes the privileges of bdr_read_all_stats, with some extra privileges for monitoring."
  :ref:`Eager <PGD predefined roles>` ,The minimal privileges required by applications running PGD.
  :ref:`Eager <PGD predefined roles>` ,Can view all conflicts in  :ref:``bdr.conflict_history`  columns<`bdr.conflict_history`  columns>` .

These roles are named to be analogous to PostgreSQL’s ``pg_``
 `predefined roles <https://www.postgresql.org/docs/current/predefined-roles.html>`_  :

The PGD ``bdr_`` roles are created when the BDR extension is installed.
See :ref:`PGD predefined roles <PGD predefined roles>`  for more details of the privileges each one has.

Managing PGD doesn’t require that administrators have access to user
data.

Arrangements for securing information about conflicts are discussed in
:ref:`Logging conflicts to a table <Logging conflicts to a table>`  .

You can monitor conflicts using the :ref:`bdr.conflict_history_summary <bdr.conflict_history_summary>`  view.

..  Note The BDR extension and superuser access::
   The one exception to the rule of not needing superuser access is in the management of PGD's underlying BDR extension. Only superusers can create the BDR extension. However, if you want, you can set up the `pgextwlist`  extension and configure it to allow a non-superuser to create a BDR extension.