Radim Marek：在主库之外读取自己的写入
内容提要
PostgreSQL 19新增WAIT FOR LSN命令，用于解决副本读取延迟问题。应用可在写入后获取LSN，并在副本上等待该位置重放完成后再读取，确保数据一致性。相比固定延迟或主库读取，此方法更精准高效，但需注意超时预算、连接池限制及框架兼容性。实测显示，WAIT FOR将延迟降至毫秒级，且正确率100%。
延伸解读
WAIT FOR 的适用边界
WAIT FOR 只保证你持有 LSN 的那次写入在副本上可见，并不能解决所有副本延迟问题。并发写入、其他事务的提交，仍可能在你读取时尚未重放。因此，它适合“读己之写”场景，而非通用的一致性方案。若业务能容忍一定程度的陈旧读，则无需引入此机制。
超时预算与连接池的权衡
TIMEOUT 不是正确性开关，而是路由决策：超时后应回退到主库或失败。但集群级延迟事件会导致大量等待者同时超时，形成对主库的流量冲击，且等待期间占用连接，可能耗尽连接池。因此，超时预算需结合连接池大小和并发量设计，并监控回退率。
框架兼容性：Rails 的坑
Active Record 将 WAIT FOR 识别为写操作，导致在只读角色上被阻止。需绕过语句层，直接使用底层连接执行。这是与 DECLARE CURSOR 等同类的问题，需等待框架更新。其他驱动通常无需特殊处理，但需注意预处理语句缓存和连接池的节点亲和性。
Q&A
PostgreSQL 19 新增的 WAIT FOR LSN 命令有什么作用？
WAIT FOR LSN 命令用于在备库上等待指定的 WAL 位置重放完成，从而确保读取到已提交的数据，解决副本读取延迟导致的数据不一致问题。
如何解决应用读取副本时出现的数据延迟问题？
可以使用 PostgreSQL 19 的 WAIT FOR LSN 命令：在写入后获取 LSN，然后在副本上等待该位置重放完成后再读取。相比固定延迟或主库读取，这种方法更精准高效。
WAIT FOR LSN 与同步提交（synchronous_commit）相比有什么优势？
同步提交（特别是 remote_apply）会让所有写入等待备库重放，增加所有写入的延迟；而 WAIT FOR LSN 只让需要读取副本的请求等待，将成本转移到需要一致性的读取上，更精准且开销更小。
使用 WAIT FOR LSN 时，TIMEOUT 参数的作用是什么？超时后应该怎么办？
TIMEOUT 参数指定等待的最大时间。超时意味着副本落后太多，此时应该回退到主库读取或失败请求，而不是继续等待。超时时间需要根据架构和连接池大小来设置。
在事务中获取 LSN 时，应该使用 pg_current_wal_flush_lsn() 还是 pg_current_wal_insert_lsn()？为什么？
应该在提交后使用 pg_current_wal_flush_lsn()。如果在事务内使用 pg_current_wal_insert_lsn()，获取的位置可能不包含提交记录，等待该位置无法保证数据对查询可见。
WAIT FOR LSN 在 Rails 框架中会遇到什么问题？如何解决？
Rails 的 Active Record 将 WAIT FOR 识别为写操作，导致在只读角色中被阻止。解决方法是通过 raw_connection 直接执行 WAIT FOR 语句，绕过 Active Record 的语句分类。
使用 WAIT FOR LSN 时，连接池和负载均衡器需要注意什么？
等待期间会占用连接，超时预算需考虑连接池大小。负载均衡器可能将等待和读取发送到不同副本，导致等待无效，因此需要确保等待和读取在同一节点上。
WAIT FOR LSN 在哪些情况下不能使用？
不能在函数、过程或 DO 块中使用，也不能在隔离级别高于 READ COMMITTED 的事务中使用。此外，如果节点不是备库（如已提升为主库），WAIT FOR 会返回错误。
