Conflict functions v5.6
bdr.alter_table_conflict_detection
Allows the table owner to change how conflict detection works for a given table.
Synopsis
Parameters
relation
— Name of the relation for which to set the new conflict detection method.method
— The conflict detection method to use.column_name
— The column to use for storing the column detection data. This can be skipped, in which case the column name is chosen based on the conflict detection method. Therow_origin
method doesn't require an extra column for metadata storage.
The recognized methods for conflict detection are:
row_origin
— Origin of the previous change made on the tuple (see Origin conflict detection). This is the only method supported that doesn't require an extra column in the table.row_version
— Row version column (see Row version conflict detection).column_commit_timestamp
— Per-column commit timestamps (described in CLCD).column_modify_timestamp
— Per-column modification timestamp (described in CLCD).
Notes
For more information about the difference between column_commit_timestamp
and column_modify_timestamp
conflict detection methods, see Current versus commit timestamp.
This function uses the same replication mechanism as DDL
statements. This means the replication is affected by the ddl filters configuration.
The function takes a DML
global lock on the relation for which column-level conflict resolution is being enabled.
This function is transactional. You can roll back the effects with the ROLLBACK
of the transaction, and the changes are visible to the current transaction.
Only the owner of the relation
can execute the bdr.alter_table_conflict_detection
function unless bdr.backwards_compatibility
is set to 30618 or less.
Warning
When changing the conflict detection method from one that uses an extra column to store metadata, that column is dropped.
Warning
This function disables CAMO and gives a warning, as long as warnings aren't disabled with bdr.camo_enable_client_warnings
.
bdr.alter_node_set_conflict_resolver
This function sets the behavior of conflict resolution on a given node.
Synopsis
Parameters
node_name
— Name of the node that's being changed.conflict_type
— Conflict type for which to apply the setting (see List of conflict types).conflict_resolver
— Resolver to use for the given conflict type (see List of conflict resolvers).
Notes
Currently you can change only the local node. The function call isn't replicated. If you want to change settings on multiple nodes, you must run the function on each of them.
The configuration change made by this function overrides any default behavior of conflict resolutions specified by bdr.create_node_group
or bdr.alter_node_group
.
This function is transactional. You can roll back the changes, and they are visible to the current transaction.
bdr.alter_node_set_log_config
Set the conflict logging configuration for a node.
Synopsis
Parameters
node_name
— Name of the node that's being changed.log_to_file
— Whether to log to the node log file.log_to_table
— Whether to log to thebdr.conflict_history
table.conflict_type
— Conflict types to log. NULL (the default) means all.conflict_resolution
— Conflict resolutions to log. NULL (the default) means all.
Notes
You can change only the local node. The function call isn't replicated. If you want to change settings on multiple nodes, you must run the function on each of them.
This function is transactional. You can roll back the changes, and they're visible to the current transaction.
Listing conflict logging configurations
The view bdr.node_log_config
shows all the logging configurations. It lists the name of the logging configuration, where it logs, and the conflict type and resolution it logs.
Logging conflicts to a table
If log_to_table
is set to true, conflicts are logged to a table. The target table for conflict logging is bdr.conflict_history
.
This table is range partitioned on the column local_time
. The table is managed by autopartition. By default, a new partition is created for every day, and conflicts of the last one month are maintained. After that, the old partitions are dropped. Autopartition creates between 7 and 14 partitions in advance. bdr_superuser can change these defaults.
Since conflicts generated for all tables managed by PGD are logged to this table, it's important to ensure that only legitimate users can read the conflicted data. PGD does this by defining ROW LEVEL SECURITY policies on the bdr.conflict_history
table. Only owners of the tables are allowed to read conflicts on the respective tables. If the underlying tables have RLS policies defined, enabled, and enforced, then even owners can't read the conflicts. RLS policies created with the FORCE option also apply to owners of the table. In that case, some or all rows in the underlying table might not be readable even to the owner. So PGD also enforces a stricter policy on the conflict log table.
The predefined role bdr_read_all_conflicts can be granted to users who need to see all conflict details logged to the bdr.conflict_history
table without also granting them bdr_superuser role.
The default role bdr_read_all_stats has access to a catalog view called bdr.conflict_history_summary
. This view doesn't contain user data, allowing monitoring of any conflicts logged.