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

Срабатывает дополнительное протоколирование и собирается статистика по конфликту (отображается в представлении pg_stat_subscription_stats) в следующих случаях возникновения конфликта:

Обратите внимание, что существуют другие сценарии конфликтов, например нарушение ограничений-исключений. На данный момент подробной информации о них в журнале не предоставляется.

Формат журнала для конфликтов логической репликации выглядит так:

LOG: conflict detected on relation "имя_схему.имя_таблицы": conflict=типа_конфликта
DETAIL:  детальная_информация.
{информация_о_значениях [; ... ]}.

где информация_о_значениях является одним из следующего:

    Key (имя_столбца [, ...])=(значение_столбца [, ...])
    existing local row [(имя_столбца [, ...])=](значение_столбца [, ...])
    remote row [(>имя_столбца [, ...])=](значение_столбца [, ...])
    replica identity {(>имя_столбца [, ...])=(значение_столбца [, ...]) | full [(c>имя_столбца [, ...])=](значение_столбца [, ...])}

В журнале представлена следующая информация:

Операции логической репликации выполняются с правами роли, которой принадлежит подписка. Поэтому при отсутствии необходимых прав доступа к целевым таблицам возникнут конфликты репликации, как и при включённой для целевых таблиц защите на уровне строк, ограничивающей владельца подписки. При этом не имеет значения, существует ли политика, которая бы запрещала реплицируемые операции INSERT, UPDATE, DELETE или TRUNCATE. Ограничение, связанное с защитой на уровне строк, может быть убрано в следующих версиях PostgreSQL.

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

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

ERROR:  conflict detected on relation "public.test": conflict=insert_exists
DETAIL:  Key already exists in unique index "t_pkey", which was modified locally in transaction 740 at 2024-06-26 10:47:04.727375+08.
Key (c)=(1); existing local row (1, 'local'); remote row (1, 'remote').
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. Обратите внимание: когда пропускается вся транзакция, пропускаются все её изменения, в том числе не нарушающие никаких ограничений. В результате состояние подписчика легко может оказаться несогласованным. Дополнительная информация по конфликтующим строкам, например их источник и время фиксации, представлена в строке журнала DETAIL. Она доступна, только если подписчике включён параметр track_commit_timestamp. На основе этой информации пользователи могут решить, оставить локальное или применить удалённое изменение. Например, вышеуказанная строка DETAIL в журнале указывает на то, что существующая строка была изменена локально. Применить удалённое изменение пользователи могут вручную.

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