Known issues v5.6
These are currently known issues in EDB Postgres Distributed 5. These known issues are tracked in PGD's ticketing system and are expected to be resolved in a future release.
If the resolver for the
update_origin_change
conflict is set toskip
,synchronous_commit=remote_apply
is used, and concurrent updates of the same row are repeatedly applied on two different nodes, then one of the update statements might hang due to a deadlock with the PGD writer. As mentioned in Conflicts,skip
isn't the default resolver for theupdate_origin_change
conflict, and this combination isn't intended to be used in production. It discards one of the two conflicting updates based on the order of arrival on that node, which is likely to cause a divergent cluster. In the rare situation that you do choose to use theskip
conflict resolver, note the issue with the use of theremote_apply
mode.The Decoding Worker feature doesn't work with CAMO/Eager/Group Commit. Installations using CAMO/Eager/Group Commit must keep
enable_wal_decoder
disabled.Lag Control doesn't adjust commit delay in any way on a fully isolated node, that's in case all other nodes are unreachable or not operational. As soon as at least one node connects, replication Lag Control picks up its work and adjusts the PGD commit delay again.
For time-based Lag Control, PGD currently uses the lag time, measured by commit timestamps, rather than the estimated catch up time that's based on historic apply rates.
Changing the CAMO partners in a CAMO pair isn't currently possible. It's possible only to add or remove a pair. Adding or removing a pair doesn't require a restart of Postgres or even a reload of the configuration.
Group Commit can't be combined with CAMO.
Transactions using Eager Replication can't yet execute DDL. The TRUNCATE command is allowed.
Parallel Apply isn't currently supported in combination with Group Commit. Make sure to disable it when using Group Commit by either (a) Setting
num_writers
to 1 for the node group usingbdr.alter_node_group_config
or (b) using the GUCbdr.writers_per_subscription
. See Configuration of generic replication.There currently is no protection against altering or removing a commit scope. Running transactions in a commit scope that's concurrently being altered or removed can lead to the transaction blocking or replication stalling completely due to an error on the downstream node attempting to apply the transaction. Make sure that any transactions using a specific commit scope have finished before altering or removing it.
The PGD CLI can return stale data on the state of the cluster if it's still connecting to nodes that were previously parted from the cluster. Edit the
pgd-cli-config.yml
file, or change your--dsn
settings to ensure only active nodes in the cluster are listed for connection.When using
bdr.add_commit_scope
, if a new commit scope is added that has the same name as a commit scope on any group, then the commit scope silently overwrites the commit scope but retains the original group the scope was associated with (if any). To modify a commit scope safely, usebdr.alter_commit_scope
.DDL run in serializable transactions can face the error:
ERROR: could not serialize access due to read/write dependencies among transactions
. A workaround is to run the DDL outside serializable transactions.The EPAS 17 data type
BFILE
is not currently supported. This is due toBFILE
being a file reference that is stored in the database, and the file itself is stored outside the database and not replicated.
Details of other design or implementation limitations are also available.