diff options
| author | Amit Kapila <akapila@postgresql.org> | 2024-08-20 08:35:11 +0530 |
|---|---|---|
| committer | Amit Kapila <akapila@postgresql.org> | 2024-08-20 08:35:11 +0530 |
| commit | 9758174e2e5cd278cf37e0980da76b51890e0011 (patch) | |
| tree | 9ca019972be8f6b4b20acd98cdeb12a9475851e9 /src/backend/executor/execIndexing.c | |
| parent | adf97c1562380e02acd60dc859c289ed3a8352ee (diff) | |
| download | postgresql-9758174e2e5cd278cf37e0980da76b51890e0011.tar.gz postgresql-9758174e2e5cd278cf37e0980da76b51890e0011.zip | |
Log the conflicts while applying changes in logical replication.
This patch provides the additional logging information in the following
conflict scenarios while applying changes:
insert_exists: Inserting a row that violates a NOT DEFERRABLE unique constraint.
update_differ: Updating a row that was previously modified by another origin.
update_exists: The updated row value violates a NOT DEFERRABLE unique constraint.
update_missing: The tuple to be updated is missing.
delete_differ: Deleting a row that was previously modified by another origin.
delete_missing: The tuple to be deleted is missing.
For insert_exists and update_exists conflicts, the log can include the origin
and commit timestamp details of the conflicting key with track_commit_timestamp
enabled.
update_differ and delete_differ conflicts can only be detected when
track_commit_timestamp is enabled on the subscriber.
We do not offer additional logging for exclusion constraint violations because
these constraints can specify rules that are more complex than simple equality
checks. Resolving such conflicts won't be straightforward. This area can be
further enhanced if required.
Author: Hou Zhijie
Reviewed-by: Shveta Malik, Amit Kapila, Nisha Moond, Hayato Kuroda, Dilip Kumar
Discussion: https://postgr.es/m/OS0PR01MB5716352552DFADB8E9AD1D8994C92@OS0PR01MB5716.jpnprd01.prod.outlook.com
Diffstat (limited to 'src/backend/executor/execIndexing.c')
| -rw-r--r-- | src/backend/executor/execIndexing.c | 17 |
1 files changed, 11 insertions, 6 deletions
diff --git a/src/backend/executor/execIndexing.c b/src/backend/executor/execIndexing.c index 9f05b3654c1..403a3f40551 100644 --- a/src/backend/executor/execIndexing.c +++ b/src/backend/executor/execIndexing.c @@ -207,8 +207,9 @@ ExecOpenIndices(ResultRelInfo *resultRelInfo, bool speculative) ii = BuildIndexInfo(indexDesc); /* - * If the indexes are to be used for speculative insertion, add extra - * information required by unique index entries. + * If the indexes are to be used for speculative insertion or conflict + * detection in logical replication, add extra information required by + * unique index entries. */ if (speculative && ii->ii_Unique) BuildSpeculativeIndexInfo(indexDesc, ii); @@ -519,14 +520,18 @@ ExecInsertIndexTuples(ResultRelInfo *resultRelInfo, * * Note that this doesn't lock the values in any way, so it's * possible that a conflicting tuple is inserted immediately - * after this returns. But this can be used for a pre-check - * before insertion. + * after this returns. This can be used for either a pre-check + * before insertion or a re-check after finding a conflict. + * + * 'tupleid' should be the TID of the tuple that has been recently + * inserted (or can be invalid if we haven't inserted a new tuple yet). + * This tuple will be excluded from conflict checking. * ---------------------------------------------------------------- */ bool ExecCheckIndexConstraints(ResultRelInfo *resultRelInfo, TupleTableSlot *slot, EState *estate, ItemPointer conflictTid, - List *arbiterIndexes) + ItemPointer tupleid, List *arbiterIndexes) { int i; int numIndices; @@ -629,7 +634,7 @@ ExecCheckIndexConstraints(ResultRelInfo *resultRelInfo, TupleTableSlot *slot, satisfiesConstraint = check_exclusion_or_unique_constraint(heapRelation, indexRelation, - indexInfo, &invalidItemPtr, + indexInfo, tupleid, values, isnull, estate, false, CEOUC_WAIT, true, conflictTid); |