复制原点旨在让在逻辑解码之上实现逻辑复制解决方案变得更加容易。它们为两个常见问题提供了解决方案

复制原点只有两个属性，一个名称和一个 ID。名称用于在各个系统中引用原点，是自由格式的 text。应以一种方式使用它，使由不同的复制解决方案创建的复制原点之间不太可能发生冲突；例如，通过在其前面加上复制解决方案的名称。ID 仅用于避免在空间效率很重要的情况下存储长版本。它绝不应在各个系统之间共享。

可以使用函数 pg_replication_origin_create() 创建复制原点；使用 pg_replication_origin_drop() 删除复制原点；并在 pg_replication_origin 系统目录中查看复制原点。

构建复制解决方案的一个非平凡部分是以安全的方式跟踪重放进度。当应用进程或整个集群死亡时，需要找出数据已成功复制到什么位置。对此的简单解决方案，例如为每个重放的事务更新表中的一行，存在诸如运行时开销和数据库膨胀等问题。

使用复制原点基础结构，可以将会话标记为从远程节点重放（使用 pg_replication_origin_session_setup() 函数）。此外，可以使用 pg_replication_origin_xact_setup() 根据每个事务配置 LSN 和每个源事务的提交时间戳。如果这样做，复制进度将以防崩溃的方式持久保存。可以在 pg_replication_origin_status 视图中查看所有复制原点的重放进度。可以使用 pg_replication_origin_progress() 获取单个原点的进度，例如在恢复复制时，或使用 pg_replication_origin_session_progress() 获取在当前会话中配置的原点的进度。

在比从一个系统到另一个系统的复制更复杂的复制拓扑中，另一个问题可能是难以避免再次复制已重放的行。这会导致复制中的循环和效率低下。复制源提供了一种识别和防止此问题的可选机制。当使用前一段中引用的函数进行配置时，由会话生成的传递给输出插件回调的每个更改和事务（参见第 49.6 节）都会标记为生成会话的复制源。这允许在输出插件中以不同的方式处理它们，例如，忽略除本地源行之外的所有行。此外，filter_by_origin_cb回调可用于根据源筛选逻辑解码更改流。虽然灵活性较低，但通过该回调进行筛选比在输出插件中执行筛选要高效得多。