Custom conflict-handling function v7

An update/update conflict occurs with at least one conflicting column in the table.

A column is considered a conflicting column if it's updated on more than one primary node in the same synchronization. Even if the new, updated value for the column is identical in the conflicting update transactions, the fact that the same column was updated on more than one primary node makes it a conflicting column.

Each publication table must have its own custom conflict-handling function to handle custom resolution for update/update conflicts on that publication table.

Custom conflict handling is designed to provide one of the following three outcomes based on how you set the resolution_code parameter:

  • Columns are set to the source node. When you set the resolution_code parameter of the function to 1, the setting of all columns in both conflicting nodes is obtained from the source node of the replication.
  • Columns are set to the target node. When you set the resolution_code parameter of the function to 2, the setting of all columns in both conflicting nodes is obtained from the target node of the replication.
  • The function logic sets the column. When you set the resolution_code parameter of the function to 3, the setting of the first conflicting column is obtained from the value returned in the source parameter coded in the function logic. The setting of all other column values is obtained from the source node of the replication.

The following is an example of a custom conflict-handling function where the conflicting columns are set to the target node.

CREATE OR REPLACE FUNCTION edb.custom_conflict_dept (
    INOUT   source              _edb_replicator_pub.rrst_edb_dept,
    IN      target              _edb_replicator_pub.rrst_edb_dept,
    IN      conflict_column     VARCHAR(255),
    OUT     resolution_message  VARCHAR(255),
    OUT     resolution_code     INTEGER
)
AS
$$
DECLARE
BEGIN
    resolution_code := 2;
    resolution_message := 'Custom conflict handling: Target node wins on edb.dept ';
END;
$$
LANGUAGE plpgsql;

If the multi-master replication system is configured with the log-based method of synchronization replication, the shadow tables of the INOUT source and IN target parameters are replaced with the actual publication tables, as shown by the following:

CREATE OR REPLACE FUNCTION edb.custom_conflict_dept (
    INOUT   source              edb.dept,
    IN      target              edb.dept,
    IN      conflict_column     VARCHAR(255),
    OUT     resolution_message  VARCHAR(255),
    OUT     resolution_code     INTEGER
)
AS
$$
DECLARE
BEGIN
    resolution_code := 2;
    resolution_message := 'Custom conflict handling: Target node wins on edb.dept ';
END;
$$
LANGUAGE plpgsql;

The following is an example of a custom conflict-handling function where the function logic determines the value of the first conflicting column.

CREATE OR REPLACE FUNCTION edb.custom_conflict_emp (
    INOUT   source              _edb_replicator_pub.rrst_edb_emp,
    IN      target              _edb_replicator_pub.rrst_edb_emp,
    IN      conflict_column     VARCHAR(255),
    OUT     resolution_message  VARCHAR(255),
    OUT     resolution_code     INTEGER
)
AS
$$
DECLARE
BEGIN
    resolution_code := 3;
    source.ename := 'Unknown';
    source.job := 'Unknown';
    source.mgr := 0;
    source.hiredate := '2013-01-01';
    source.sal := 0;
    source.comm := 0;
    resolution_message := 'Custom conflict handling: Defaults set on edb.emp';
END;
$$
LANGUAGE plpgsql;

In this example, only the first conflicting column (based on the column order in the table) is set to the value coded in the function. All other assignments to the source parameter are ignored. These other columns are set to the source node.

Function parameters

source

INOUT parameter of the record type of the shadow table in schema _edb_replicator_pub of the primary definition node on which to resolve the conflicts. If you use the log-based method of synchronization replication, specify the actual publication table instead of the shadow table. The input values are the column values from the source node. When resolution_code is set to 3, set the columns in this parameter to the values to use for the final outcome.

target

IN parameter of the record type of the shadow table in schema _edb_replicator_pub of the primary definition node on which to resolve conflicts. If you use the log-based method of synchronization replication, specify the actual publication table instead of the shadow table. The input values are the column values from the target node.

conflict_column

IN parameter of type VARCHAR(255) containing the name of the column on which the update/update conflict occurred. If more than one column is involved in the conflict, the name of the first conflicting column is returned.

resolution_message

OUT parameter of type VARCHAR(255) containing an informative message to write to the publication server log file. Set the publication server configuration option logging.level to at least the INFO level for the messages to appear in the publication server log file. See Installation details for the location of the publication server log file.

resolution_code

OUT parameter of type INTEGER that you set to one of the following values to determine how to resolve the conflict:

  • 1 to use the column values of the source node of the replication for the final outcome
  • 2 to use the column values of the target node of the replication for the final outcome
  • 3 to use the value set for the source INOUT parameter of the first conflicting column as the final outcome for that column.