Appendix B: Known Issues v3.7

Suggest edits

This section discusses currently known issues in BDR3.

Data Consistency

Please remember to read about Conflicts to understand the implications of the asynchronous operation mode in terms of data consistency.

List of Issues

In the remaining part of this section we list a number of known issues that are tracked in BDR3's ticketing system, each marked with an unique identifier.

  • If the resolver for the update_origin_change conflict is set to skip, and 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 pglogical writer. As mentioned in the Conflicts chapter, skip is not the default resolver for the update_origin_change conflict, and this combination is not 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 the skip conflict resolver, please note the issue with the use of the remote_apply mode.

  • A galloc sequence might skip some chunks if the sequence is created in a rolled back transaction and then created again with the same name, or if it is created and dropped when DDL replication is not active and then it is created again when DDL replication is active. The impact of the problem is mild, because the sequence guarantees are not violated; the sequence will only skip some initial chunks. Also, as a workaround the user can specify the starting value for the sequence as an argument to the bdr.alter_sequence_set_kind() function.

  • Upgrades on 2ndQPostgres 13 from BDR 3.7.7 are only supported by adding new nodes, and not through in-place upgrade of the same data directory.

  • The bdr.monitor_local_replslots() function may return CRITICAL result saying "There is at least 1 BDR replication slot which is missing" even if all slots exists in presence of logical standbys or subscribe-only node groups.

  • Decoding Worker feature does not work with CAMO/EAGER

  • Decoding Worker works only with the default replication sets

← Prev

Appendix B: Conflict Details

Next →

Appendix C: CAMO Reference Client Implementations