Skipping conflicting transactions can cause subscriber data inconsistency

When using ALTER SUBSCRIPTION ... SKIP or pg_replication_origin_advance() to resolve conflicts by skipping transactions, the entire transaction is skipped including changes that may not violate constraints. This can make the subscriber inconsistent with the publisher.

Before skipping a conflicting transaction, analyze the full transaction contents if possible. Use track_commit_timestamp data in DETAIL logs to understand conflict origin and timestamps - this helps decide whether to retain local changes or adopt remote changes. Consider manually applying non-conflicting changes from the skipped transaction. Document all transaction skips for future reconciliation. In some cases, rebuilding the subscription from a fresh snapshot may be safer than accumulating skipped transactions.