近期，PostgreSQL社区在邮件列表和社交媒体上围绕多个核心议题展开了深入讨论，从存储引擎的性能比较到内核锁机制的优化，再到WAL（预写式日志）功能的增强，这些动态共同描绘了数据库技术持续演进的脉络。
TimescaleDB 在可观测性场景下的性能表现
在一篇技术分享中，LogTide创始人详细阐述了为何在构建这个面向家庭实验室和小企业的开源可观测平台时，选择了TimescaleDB 而非 ClickHouse 或 MongoDB 作为核心存储方案。
LogTide的设计目标颇具挑战性：希望在仅占用 2GB 内存的情况下，每日处理数百万条日志。最终选择 TimescaleDB，一个重要的考量是其与 PostgreSQL 的完全兼容性，这帮助团队有效避免了厂商锁定风险，并简化了运维复杂度。
在实际的生产环境测试中，TimescaleDB 展现出了显著优势。通过其原生的列式压缩功能，成功将 220GB 的原始日志数据压缩至 25GB。更令人印象深刻的是，查询性能也因此提升了 33-41%。在专门的基准测试中，数据显示在典型的批次大小下，TimescaleDB 的插入性能可达每秒 14200 次，而作为对比的 ClickHouse 仅为每秒 250 次。在进行过滤查询时，TimescaleDB 的响应速度更是比 MongoDB 快了 650 倍。
该平台充分利用了 TimescaleDB 的超表（hypertable）和连续聚合（continuous aggregates）特性来实现实时数据仪表板，并通过自动化的数据保留策略来管理整个数据生命周期。
相关阅读：https://www.tigerdata.com/blog/clickhouse-is-fast-your-pipeline-isnt
PostgreSQL Hacker 邮件讨论精选
REPACK 并发选项的死锁预防机制
近期邮件列表中的讨论，聚焦于在 PostgreSQL 中实现 REPACK CONCURRENTLY 功能时，如何有效预防死锁。Andres Freund 提出了一种观点，他认为应该将死锁检测的逻辑集成到数据库内核的锁管理器中，而不是在队列系统中实施一些临时的变通方案。
他的理由是，简单的处理方式可能无法应对现实中复杂的锁循环情况，尤其是当触发等待的操作并非直接针对正在重组（repack）的表时。另一位开发者 Antonin Houska 探讨了使用“假设图（hypothetical graphs）”的方法来预测死锁，但在评估中发现，这种方法要求在每次锁插入时都获取所有锁管理器的轻量级锁，这可能会带来显著的性能开销。
随后，Mihail Nikalayeu 提出了一种新思路：在检测到潜在冲突时，触发其他相关进程的死锁检测流程。这个方法让 Houska 觉得很有前景。然而，他仍然对 Freund 建议的死锁检查时机表示担忧。他指出，即使在 REPACK 操作期间进行早期检测，也无法完全阻止其他会话在检测完成和实际锁升级之间的短暂窗口期内制造新的死锁条件。目前，关于最优实现策略的争论仍在继续。
讨论链接：https://www.postgresql.org/message-id/%3C25514.1776264611@localhost%3E
WAL LSN 回放等待机制的重新设计
开发者 Xuneng Zhou 和 Alexander Korotkov 正在合作，致力于实现更完善的 WAL LSN 回放等待功能。他们整合了多个补丁来解决一系列复杂问题：
- 补丁 0001 根据 Andres 的建议，为
GetWalRcvWriteRecPtr() 函数添加了内存屏障。
- 补丁 0002 修订了
GetCurrentLSNForWaitType() 函数，并确保无条件调用 ResetLatch()。
- 补丁 0003 至 0005 则重点解决了在纯归档恢复期间可能出现的一个棘手问题。该问题的核心在于：当启动进程（startup process）仅唤醒
STANDBY_REPLAY 类型的等待者时，standby_write 类型的等待者可能会永远陷入休眠状态。
这个问题也会影响混合场景，即当 walreceiver 进程的进度滞后于 replay 进程时。Zhou 发现并为此类边缘情况创建了补丁，在这些情况下，等待者可能被卡住，等待去消费那些已经被回放（replay）处理过的 WAL 日志位置。目前，Korotkov 已将所有这些补丁添加到 Commitfest 中，等待 CI 测试和社区的进一步审查。
讨论链接：https://www.postgresql.org/message-id/%3CCABPTF7W=P_PiKQ5SW-WmadC9vJ=q67MOwGM6iNRwSERF7OF0WA@mail.gmail.com%3E
社交媒体与行业动态
2026 数据与 AI 峰会预告
2026 年数据与 AI 峰会（Data+AI Summit）已定于 6 月 15 日至 18 日举行。据悉，本届峰会将包含超过 800 场会议，核心主题是如何通过数据和人工智能技术推动组织的全面转型。
活动内容将广泛涵盖多个前沿领域，包括构建基于数据的精准 AI 智能体、使用托管的 PostgreSQL 数据库开发智能应用，以及如何将数据、分析和 AI 工作流进行统一并内置治理功能。会议计划分为九个主题方向，旨在为参会者提供实用的技术见解和真实的案例研究。组织方表示，在 4 月 30 日前完成早鸟注册可享受半价优惠，门票费用包含实操培训课程和相关的认证项目。
详情：https://www.linkedin.com/posts/databricks_dataaisummit-activity-7450265982486454273-Q5E9
Databricks AI Gateway 扩展治理能力
Databricks 近日宣布，其 AI Gateway 产品现已将 Unity Catalog 的治理能力扩展至智能体（Agent）AI 系统。随着 AI 智能体日益普及，它们在与大语言模型交互、通过模型上下文协议（MCP）服务器获取数据以及调用外部 API 时，往往会处理大量敏感信息。如何为这些 AI 交互提供适当的审计与治理呢？
更新后的 AI Gateway 试图通过一个统一的治理模型来实现集中管理。这意味着企业组织可以针对所有接入的大语言模型和工具设置统一的访问策略，并对智能体产生的数据流进行端到端的追踪，旨在实现对 AI 应用生命周期的全面管控。
详情：https://www.linkedin.com/posts/databricks_ai-gateway-in-databricks-now-extends-unity-activity-7450212550081740801-NIgY
以上便是近期围绕 PostgreSQL 及其生态的一些关键动态。从深层的内核机制优化讨论，到上层应用的技术选型实践，再到行业会议的前沿风向，这些信息共同构成了数据库技术发展的多维图景。对这些话题感兴趣的朋友，欢迎在 云栈社区 继续交流探讨。
发表于 3 小时前
|
查看: 5|
回复: 0
