⚙️ PostgreSQL技术文章
📨 PostgreSQL Hacker 电子邮件讨论精选
🧩 关于添加 REPACK [CONCURRENTLY] 功能的讨论该讨论主要围绕PostgreSQL的REPACK CONCURRENTLY功能，涉及几个技术挑战。一个主要问题是当REPACK将锁升级为AccessExclusiveLock时的死锁检测，可能导致其他进程发生死锁并丢失工作。Amit Kapila建议将表标记为"in_use_by_repack"并提前释放ShareUpdateExclusiveLock，但Andres Freund认为这种方法不够充分，因为它无法阻止所有锁获取或正确处理现有锁。另外还存在在32位系统上的编译警告问题，由于restore_tuple函数中的数组边界检查导致编译器警告。Tom Lane建议通过使用uint64变量来简化有问题的union定义。该补丁还解决了关于逻辑解码快照及其对其他进程潜在影响的担忧。讨论揭示了在实现安全的并发表重组功能时仍面临挑战，需要避免引入死锁风险。 https://www.postgresql.org/message-id/%3CCAA4eK1KWDbBk4FgbbWdivQLrPPzR4zgvfnHK4WjWC78rbuRVbg@mail.gmail.com%3E |
🧩 实现 WAL LSN 回放等待机制：重新设计讨论重点是修复 WAIT FOR LSN 功能实现中的问题。Xuneng Zhou 发现了一个严重问题：在空闲主节点上，即使目标 LSN 已经满足，WAIT FOR LSN 的 standby_write 或 standby_flush 模式仍可能无限期阻塞。这是因为共享内存位置（writtenUpto 和 flushedUpto）没有从现有的 WAL 重放位置正确初始化。目前正在开发多个补丁来解决不同方面的问题：WaitLSNWakeup() 中的内存屏障、LSN 跟踪位置的正确初始化，以及处理没有运行 walreceiver 的纯归档恢复场景。Alexander Korotkov 和 Andres Freund 正在审查补丁，讨论内存屏障放置和锁存器行为。还发现了归档恢复模式的额外问题，即启动进程不能适当唤醒 standby_write 等待者。 https://www.postgresql.org/message-id/%3CCABPTF7WC0DdMkQz1NWymS3rRSn_p09yFjM36z0CtmW3+WY0mcA@mail.gmail.com%3E |
🧩 通过 max_log_size 截断日志Fujii Masao 对 Jim Jones 的 v9 补丁进行了详细审查，该补丁为 PostgreSQL 添加了 log_statement_max_length 参数，用于将记录的 SQL 语句截断到指定的字节限制。Fujii 在功能冻结后提供了反馈，指出了几个改进方向。他建议澄清文档，说明截断仅适用于 log_statement 和 log_min_duration_statement 记录的语句，不包括错误消息。他发现了性能问题：即使不进行日志记录时也会无条件调用 truncate_query_log()，建议仅在实际日志记录路径如 check_log_statement() 和 check_log_duration() 中调用。Fujii 还建议将变量声明移到使用位置附近以提高可读性，并推荐使用更清晰的用户描述如"-1 means log statement in full"而非"-1 means no truncation"。他质疑将回归测试放在 pg_ctl 测试套件中，建议改用 test_misc。Jim Jones 实现了所有建议的更改，将截断逻辑改为仅在需要时惰性执行，更新了文档和注释，并将测试迁移到 src/test/modules/test_misc。Jones 注意到一个有趣的副作用：启用截断的命令本身成为了截断行为的第一个受害者。 https://www.postgresql.org/message-id/%3CCAHGQGwGEd=PpVWDd05bYM8F6mnxcSNmWL2Ei8JCf5azZSJnYJA@mail.gmail.com%3E |
🧩 pg_plan_advice 扩展功能的探讨讨论围绕稳定 test_plan_advice 测试套件以减少虚假失败展开。Robert Haas 提出了补丁（0001 和 0002），实现"重试几次"的方法来处理测试不稳定性，认为这是合理的提交后稳定化工作，不应被功能冻结阻止。Tom Lane 支持这个解决方案，认为比串行执行测试更好。但由于目前只观察到一次失败，对于时机存在争议——是立即应用修复还是等待数周收集更多失败数据。Nathan Bossart（RMT 成员）批准了所述计划。Melanie Plageman 同意等待以发现更多 bug，支持重试方法而非串行执行。她还讨论了 CI 集成需求和 buildfarm 部署策略，指出对于 test_plan_advice 来说，更广泛的动物覆盖可能不如时间敏感测试那么关键。 https://www.postgresql.org/message-id/%3CadZq3Rlxq3v916aG@nathan%3E |
🧩 用 rdtsc 降低 EXPLAIN ANALYZE 的时间开销？这个讨论跟进了最近实现PostgreSQL基于RDTSC计时功能的提交。Lukas报告了三个关键要点：(1) 在Linux上禁用用户模式的TSC指令应该不是实际问题，因为vDSO已经直接使用RDTSCP，不过用户可以通过timing_clock_source=system启动来完全避免RDTSC调用；(2) 质疑pg_test_timing wiki页面是否应该继续维护或迁移到主文档；(3) 计划在PostgreSQL 20的单独线程中讨论ARM支持。 编译农场成员"drongo"出现了与计时变更相关的失败，在tsm_system_time测试中显示错误结果。调查发现该系统从CPUID报告了错误的TSC频率7 kHz，而校准显示为2500044 kHz，导致计时计算严重不准确。这表明虚拟化环境中的CPUID实现存在问题。Andres建议在pg_test_timing中添加合理性检查和诊断函数来检测此类问题。Lukas提供了一个补丁，添加详细的TSC频率源信息，以帮助诊断将来类似的问题。 https://www.postgresql.org/message-id/%3CCAP53PkyZ6sbaJvMHXFD4Xpv72ZtqUe8iz_02EquFDYjdKQ2=yw@mail.gmail.com%3E |
🧩 逻辑复制中：在确认远端刷盘前关闭 walsender测试用例 038_walsnd_shutdown_timeout.pl 在 FreeBSD CI 上间歇性失败，当物理和逻辑复制都启用且开启 slotsync 时，主服务器关闭过程出现超时。该测试验证当复制阻塞时，关闭过程能通过 wal_sender_shutdown_timeout 完成。Chao Li 调查发现，walsender 在 WalSndDone() 中调用 pq_flush() 时可能卡住，导致无法返回到 WalSndCheckShutdownTimeout() 来执行超时处理。问题似乎是 FreeBSD 特有的，因为 Unix 域套接字的行为是直接写入对端接收缓冲区而没有发送缓冲区。Li 建议在 WalSndDone() 中从 pq_flush() 改为使用 pq_flush_if_writable()，类似于 WalSndDoneImmediate() 中已采用的方法。Fujii Masao 认可了这一分析，同意 FreeBSD 的套接字行为可以解释为什么关于非阻塞写入的假设不成立。 https://www.postgresql.org/message-id/%3C43F849DC-885F-4D60-94F6-78B5D645E24D@gmail.com%3E |
🌐 社交媒体动态
🧩 AI Days芝加哥站于4月1日成功举办，数百名数据和AI从业者参与了全天会议和三场实训工作坊 https://www.linkedin.com/posts/databricks_ai-days-made-a-stop-in-chicago-on-april-1-activity-7447742856255082496-lVxn |
🧩 在数据库世界中探索如同在浓雾中迷失方向 https://www.linkedin.com/posts/cybertec-postgresql_thepostgresqljourney-lostelephant-cybertec-activity-7447677971165011968-l4ac |
https://www.linkedin.com/posts/databricks_lakebase-customers-easyjet-ensemble-and-activity-7447699828265947137-UJ2b |
🔥 HOW 2026 报名进行中
