PG 19 再次提高逻辑复制可靠性

本期播客

PG 19 再次提高逻辑复制可靠性

上一个补丁被打脸了，AI错误的解读从库promote时会将restart lsn推进到current lsn，狠狠打脸。看这篇评论PostgreSQL 19 preview - 有slot同步时强制 promote

今天会不会扳回一局呢？

https://github.com/postgres/postgres/commit/0d2d4a0ec3eca64e7f5ce7f7630b56a561b2663c

这个补丁（Commit 0d2d4a0ec3eca64e7f5ce7f7630b56a561b2663c）的主要目的是为 PostgreSQL 的管理函数 pg_sync_replication_slots() 添加重试逻辑（retry logic） ，以提高其在同步复制槽时的可靠性。

以下是对该补丁的解读：

补丁解决的问题

在引入此补丁之前，pg_sync_replication_slots() 函数的行为存在一个问题：

1. 当该函数在备用服务器（standby）上运行时，如果某些复制槽（replication slots）不满足同步要求（例如，主服务器上所需的数据目录行或 WAL 段缺失，或面临被移除的风险），函数会直接完成，但不会同步这些不满足要求的槽，而是将它们遗漏。
2. 这可能导致部分用于故障转移（failover）的复制槽处于未同步状态。更糟糕的是，备用服务器可能会继续移除主服务器提升后所需的数据，从而使故障转移槽无法使用。

补丁实施的更改（解决方案）

该补丁通过引入循环重试机制来解决上述问题，确保所有必需的槽都得到同步：

1. 等待机制： 函数现在会等待主槽（primary slot）推进到一个位置，确保备用服务器上所需的所有数据（WAL 或目录行）都可用，然后再完成同步。
2. 循环重试： 它将循环重试，直到在函数调用开始时存在于主服务器上的所有故障转移槽都被同步。
3. 范围限定： 在函数开始运行后创建的槽将不会被包含在此次同步周期内。
4. 优雅退出： 如果在等待过程中备用服务器被提升为新的主服务器，该函数会优雅地退出，并移除在此过程中创建的临时槽。

简而言之，此补丁将手动同步复制槽的函数 pg_sync_replication_slots() 变得像自动同步机制一样健壮，能够处理暂时的 WAL 文件不可用等情况，显著提高了在高可用性场景中故障转移槽的可靠性。

文件变动（文档部分）

补丁也相应更新了 PostgreSQL 的 SGML 文档，确认了 pg_sync_replication_slots() 的行为变化：

• 删除了关于此函数“主要用于测试和调试，并且更容易失败”的警告。
• 明确指出该函数现在会“循环重试，直到在函数调用开始时存在于主服务器上的所有故障转移槽都被同步”。