Механизм логической репликации функционирует аналогично стандартным операциям DML: данные обновляются даже в том случае, если они были изменены локально на узле-подписчике. Если входящие данные нарушают установленные ограничения, процесс репликации приостанавливается. Данная ситуация классифицируется как конфликт. При репликации UPDATE или DELETE операций отсутствие данных не приводит к возникновению конфликта; такие операции пропускаются.

Операции логической репликации выполняются с правами роли, владеющей подпиской. Ошибки доступа к целевым таблицам приводят к конфликтам репликации, равно как и включенный механизм row-level security на целевых таблицах, ограничения которых распространяются на владельца подписки, без учета того, могла бы какая-либо политика отклонить INSERT, UPDATE, DELETE или TRUNCATE реплицируемое действие. Данное ограничение в отношении защиты строк может быть снято в одной из будущих версий Digital Q.DataBase.

Конфликт вызывает ошибку и останавливает репликацию; данная проблема должна быть устранена пользователем вручную. Подробные сведения о конфликте можно найти в журнале сервера подписчика.

Конфликт можно разрешить либо путем изменения данных или прав доступа на стороне подписчика, чтобы исключить противоречие с входящим изменением, либо путем пропуска транзакции, конфликтующей с существующими данными. Если конфликт вызывает ошибку, процесс репликации останавливается, а рабочий процесс логической репликации выводит в журнал сервера подписчика сообщение следующего вида:

ERROR:  duplicate key value violates unique constraint "test_pkey"
DETAIL:  Key (c)=(1) already exists.
CONTEXT:  processing remote data for replication origin "pg_16395" during "INSERT" for replication target relation "public.test" in transaction 725 finished at 0/14C0378

LSN транзакции, содержащей нарушающее ограничение изменение, и имя источника репликации могут быть получены из журнала сервера (в данном случае LSN 0/14C0378 и источник репликации pg_16395 ). Транзакцию, вызвавшую конфликт, можно пропустить, используя команду ALTER SUBSCRIPTION ... SKIP с указанием конечного LSN (т. е. LSN 0/14C0378). Конечным LSN может являться LSN, при котором транзакция была зафиксирована или подготовлена на издателе. Кроме того, транзакцию можно пропустить путем вызова функции pg_replication_origin_advance() функция. Перед использованием данной функции необходимо временно отключить подписку либо с помощью ALTER SUBSCRIPTION ... DISABLE либо подписка может быть использована с disable_on_error параметром. После этого можно использовать функцию pg_replication_origin_advance() с node_name (т. е. pg_16395) и LSN, следующий за конечным LSN (т. е. 0/14C0379). Текущее положение источников можно просмотреть в pg_replication_origin_status системное представление. Обратите внимание, что пропуск всей транзакции подразумевает пропуск всех изменений, включая те, которые не нарушают ограничения. Это может привести к потере согласованности данных на подписчике.

Когда потоковая передача выполняется в режиме parallel, конечный LSN незавершенных транзакций может не записываться в журнал. В таком случае может потребоваться изменить режим потоковой передачи на on или off и снова вызывать те же конфликты, поэтому конечный LSN незавершенной транзакции будет записан в журнал сервера. Информация об использовании конечного LSN приведена в ALTER SUBSCRIPTION ... SKIP.