Replication slots created by PGD
================================

On a PGD master node, the following replication slots are created by
PGD:

-  One *group slot*, named ``bdr_<database name>_<group name>``

-  N-1 *node slots*, named
   ``bdr_<database name>_<group name>_<node name>`` , where N is the
   total number of PGD nodes in the cluster, including direct logical
   standbys, if any

..  Warning::
   Don't drop those slots. PGD creates and manages them and drops them when or if necessary.

On the other hand, you can create or drop replication slots required by
software like Barman or logical replication using the appropriate
commands for the software without any effect on PGD. Don’t start slot
names used by other software with the prefix ``bdr_`` .

For example, in a cluster composed of the three nodes ``alpha`` ,
``beta`` , and ``gamma`` , where PGD is used to replicate the ``mydb``
database and the PGD group is called ``mygroup`` :

-  Node ``alpha`` has three slots:

-  One group slot named ``bdr_mydb_mygroup``

-  Two node slots named ``bdr_mydb_mygroup_beta`` and
   ``bdr_mydb_mygroup_gamma``

-  Node ``beta`` has three slots:

-  One group slot named ``bdr_mydb_mygroup``

-  Two node slots named ``bdr_mydb_mygroup_alpha`` and
   ``bdr_mydb_mygroup_gamma``

-  Node ``gamma`` has three slots:

-  One group slot named ``bdr_mydb_mygroup``

-  Two node slots named ``bdr_mydb_mygroup_alpha`` and
   ``bdr_mydb_mygroup_beta``

Group replication slot
----------------------

The group slot is an internal slot used by PGD primarily to track the
oldest safe position that any node in the PGD group (including all
logical standbys) has caught up to, for any outbound replication from
this node.

The group slot name is given by the function :ref:`bdr.local_group_slot_name() <System functions>`  .

The group slot can:

-  Join new nodes to the PGD group without having all existing nodes up
   and running (although the majority of nodes should be up). This
   process doesn’t incur data loss in case the node that was down during
   join starts replicating again.

-  Part nodes from the cluster consistently, even if some nodes haven’t
   caught up fully with the parted node.

-  Hold back the freeze point to avoid missing some conflicts.

-  Keep the historical snapshot for timestamp-based snapshots.

The group slot is usually inactive and is fast forwarded only
periodically in response to Raft progress messages from other nodes.

..  Warning::
   Don't drop the group slot. Although usually inactive, it's still vital to the proper operation of the EDB Postgres Distributed cluster. If you drop it, then some or all of the features can stop working or have incorrect outcomes.

Hashing long identifiers
------------------------

The name of a replication slot, like any other PostgreSQL identifier,
can’t be longer than 63 bytes. PGD handles this by shortening the
database name, the PGD group name, and the name of the node in case the
resulting slot name is too long for that limit. Shortening an identifier
is carried out by replacing the final section of the string with a hash
of the string itself.

For example, consider a cluster that replicates a database named
``db20xxxxxxxxxxxxxxxx`` (20 bytes long) using a PGD group named
``group20xxxxxxxxxxxxx`` (20 bytes long). The logical replication slot
associated to node ``a30xxxxxxxxxxxxxxxxxxxxxxxxxxx`` (30 bytes long) is
called since ``3597186`` , ``be9cbd0`` , and ``7f304a2`` are
respectively the hashes of ``db20xxxxxxxxxxxxxxxx`` ,
``group20xxxxxxxxxxxxx`` , and ``a30xxxxxxxxxxxxxxxxxxxxxxxxxx`` .

::

   bdr_db20xxxx3597186_group20xbe9cbd0_a30xxxxxxxxxxxxx7f304a2