⚙️ PostgreSQL技术文章
🧩 在 AWS 中构建统一的 JSON 搜索方案
这篇 AWS 博客文章介绍了如何通过结合多个专门的 AWS 服务来构建统一的 JSON 搜索解决方案，而非依赖单一数据库。作者指出，JSON 的灵活性带来了架构复杂性，需要针对操作访问、分析处理和发现操作进行不同的优化。以电影流媒体平台为例，文章展示了如何将 JSON 工作负载分布到各个服务：Amazon DynamoDB 处理实时用户状态，Amazon DocumentDB 管理电影目录，Amazon Aurora PostgreSQL 通过 ACID 保证处理计费，Amazon S3 作为数据湖存储，Amazon Redshift 使用 SUPER 数据类型进行分析，Amazon OpenSearch Service 负责内容发现。该架构使用 OpenSearch Ingestion 通过初始快照和持续的变更数据捕获在服务间同步数据，根据工作负载要求维护可接受同步窗口内的最终一致性。
https://aws.amazon.com/blogs/database/how-to-build-unified-json-search-solutions-in-aws/
🧩 迁移的最佳时机是在 1000 万行数据时。第二好的时机就是现在
本文讨论了从原生PostgreSQL迁移到TimescaleDB处理大量时间序列数据的最佳时机。作者认为团队应该在早期迁移，最好是在1000万行数据左右，而不是等到性能问题变得严重。文章描述了一个可预测的模式：最初良好的性能随着数据增长而恶化，导致越来越复杂的优化工作。在1000万行时，迁移只是一个简单的周末任务，但在5亿行以上时就变成了需要多名工程师的数周项目。作者提出了"优化税"的概念，即通过查询调优、基础设施扩展和事件管理来维持原生Postgres性能的隐性持续成本。TimescaleDB的原生压缩和自动分区功能消除了这些维护负担，同时从一开始就提供更好的性能。
https://www.tigerdata.com/blog/when-to-migrate-postgres-to-timescaledb
📨 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从业者参与了全天会议和三场实训工作坊
AI Days 于4月1日在芝加哥成功举办，吸引了数百名数据和人工智能专业人士参加这场座无虚席的大会。活动包含多场会议和三个实践培训实验室，参会者学习了如何在 Databricks 平台上运行分析、构建AI应用程序，以及使用 Lakebase、Genie 和 Agent Bricks 等工具创建和部署AI智能体。活动邀请了尼尔森公司的 Christophe…
https://www.linkedin.com/posts/databricks_ai-days-made-a-stop-in-chicago-on-april-1-activity-7447742856255082496-lVxn
🧩 在数据库世界中探索如同在浓雾中迷失方向
CYBERTEC推出四集系列内容，专注于PostgreSQL指导和专业技术支持。该公司将数据库导航比作在浓雾中迷路，强调仅有前进的动力还不够，还需要正确的方向指引。他们将自己定位为数据库专业人员的向导，帮助解决性能瓶颈、配置难题或不知从何开始的困惑。这个系列探讨了在PostgreSQL实施和管理初期阶段，专家指导的重要性，认为数据库之旅不应该独自进行。
https://www.linkedin.com/posts/cybertec-postgresql_thepostgresqljourney-lostelephant-cybertec-activity-7447677971165011968-l4ac
🧩 易捷航空、EnsembleHealth Partners和Hafnia等跨行业公司在分散系统和手动工作流方面遭遇瓶颈
易捷航空、Ensemble Health Partners和Hafnia三家不同行业的公司都面临着系统分散和手动工作流程的挑战。通过使用Databricks Lakebase，这些公司通过连接交易数据和分析数据，同时支持运营应用程序，彻底改变了数据运营方式。易捷航空通过分析集成提升了定价决策速度，Ensemble统一了医疗数据以支持收入回收，Hafnia在…
https://www.linkedin.com/posts/databricks_lakebase-customers-easyjet-ensemble-and-activity-7447699828265947137-UJ2b
🔥 HOW 2026 报名进行中
一场真正以技术为核心的 PostgreSQL 大会
HOW 2026 PostgreSQL & IvorySQL 技术峰会火热报名中
📍 2026 年 4 月 27 日 - 28 日｜济南
454
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
