⚙️ PostgreSQL技术文章
📨 PostgreSQL Hacker 电子邮件讨论精选
🧩 关于 REPACK [concurrently] 的讨论讨论的焦点是 REPACK CONCURRENTLY 功能中的锁冲突处理问题。Srinath 测试了 Alvaro 的死锁检测器方案,该方案能够成功处理查询等待 REPACK 操作的情况。然而,仍存在一个相反的问题场景:当现有事务持有冲突锁(如 SELECT 语句的 AccessShareLock)阻止 REPACK 最终的 AccessExclusiveLock 升级时,由于不存在循环等待,死锁检测器不会触发。REPACK 只是等待,达到锁超时后中止,浪费了可能数小时或数天的工作。Srinath 提议在最终交换阶段主动取消冲突会话,类似于 ResolveRecoveryConflictWithLock 的做法。Alvaro 同意这种方法可能是合适的,强调 REPACK 的工作通常很关键,不应该丢失。Antonin 质疑为什么用户要在运行 REPACK 前设置非零的锁超时。 https://www.postgresql.org/message-id/CAFC+b6of6_poBQ6EgK8N49VQwAUYX=uLkHiU-TP7y+DamBD5TQ@mail.gmail.com |
🧩 减少 WAL 日志:移除 xl_heap_visible 记录(并最终改为访问时设置 VM)Melanie Plageman已经提交了消除xl_heap_visible WAL记录的补丁,用于减少预写日志的开销。David Rowley审查了最终版本(v48-0001),并提出了一个小建议:在standard_planner()中填充Bitmapsets时,应该使用foreach_int()和foreach_node()而不是通用的foreach()循环。Melanie承认了这个疏漏并提供了后续补丁来修复已提交的代码。由于代码已经合并到主分支,David建议在当前功能冻结结束后,对整个代码库中类似的foreach()使用模式进行更全面的清理,特别是针对版本19中引入的代码变更。Melanie同意了这个建议,并将这项更广泛的清理任务添加到她的冻结后待办清单中。 https://www.postgresql.org/message-id/CAAKRu_YfoGTHNn0XxA+dCPj9hyO96vO4Eb+awRR6T8m22qC6ww@mail.gmail.com |
🧩 缓冲区锁定的特殊性(提示、校验和、异步 I/O 写入)在Andres Freund完成缓冲区锁定项目后,Yura Sokolov在PinBuffer函数中发现了一个竞态条件问题。该问题出现在等待缓冲区解锁之前检查skip_if_not_valid时——在等待期间缓冲区可能变为无效状态,因此有效性检查应该在WaitBufHdrUnlocked()之后进行。Andres同意这是错误的,并建议添加continue语句来重启循环,而不是移动检查位置。Yura还质疑是否仍需要等待缓冲区解锁,因为UnlockBufHdr现在使用了适当的原子操作。Andres确认仍需要等待,因为某些代码依赖于在阻止新pin的同时检查缓冲区状态,仅靠分区锁无法提供充分保护。他提到计划最终将缓冲区头部自旋锁的定义缩小到仅处理缓冲区身份变更。 https://www.postgresql.org/message-id/5bf667f3-5270-4b19-a08f-0facbecdff68@postgrespro.ru |
🌐 社交媒体动态
🧩 优秀的存储系统能掩盖许多数据库问题 https://www.linkedin.com/posts/cybertec-postgresql_postgresql-dba-opensource-activity-7444758589010817024-uOKL |
🧩 [演示]GenieCode:您的自主AI数据工作伙伴 https://www.linkedin.com/posts/databricks_demo-genie-code-is-your-autonomous-ai-partner-activity-7444845121273229312-Gc5T |
🧩 2026年企业科技30强榜单发布,Databricks位列GigaStage第二名! https://www.linkedin.com/posts/databricks_et30-activity-7444813352574545920-EzUS |
🔥 HOW 2026 报名进行中











