PostgreSQL 9.1 未解决问题

项目规划

请查看 PostgreSQL 9.1 开发计划.

元问题

• standard_conforming_strings — 驱动程序和应用程序的准备情况
• 回顾 PostgreSQL 9.0 未解决问题 中的“长期”问题列表

未解决问题

下一个 Beta / RC 版本的非阻塞问题

• 为使用 SSI 的 DDL 命令添加回归测试

已解决问题

RC1 之前已解决的问题

• 如果源数据库包含孤立的临时表，pg_upgrade 就会失败
• 如果您尝试从使用 pg_basebackup 创建的不完整备份启动，则会抛出错误
  • 建议的补丁（似乎不适合放在 9.1 中，尽管如此）
• pg_restore 在 standard_conforming_strings 下失败
• 闩锁是否存在内存排序问题？
  • 是的，它们确实存在... 但是 9.1 真的容易受到攻击吗？
  • 仔细的代码检查表明我们很安全。目前来说。
• SSI 2PC 覆盖测试
  • 相关的错误已修复；需要在添加测试之前稍微缩减一下测试范围

Beta3 之前已解决的问题

• plpython 没有连接到 tarball 构建
• NOT VALID 约束的语法设计不当
• 在 README-SSI 中添加关于 READ ONLY 优化的有效性的证明
  • Dan 提供了一个简洁的证明，但我们需要一个引用来说明它使用的一个前提
  • Kevin 提供了一个自包含的证明，但它比 Dan 的证明长得多
• FOREIGN TABLE 文档修复
• SxactGlobalXmin 在中止后计算错误
  • 补丁
• 在 SSI 文档中添加一些性能说明
  • 执行此操作的补丁
• 在有损位图堆扫描中缺少谓词锁定
  • 修复的补丁
• btree_gist 破坏了一些涉及 <> 运算符的行为
• ALTER TABLE 锁强度降低补丁不安全
• SSI 原子提交补丁

Beta2 之前已解决的问题

• ALTER TYPE DROP + 复合类型列与 pg_upgrade
• 外部扫描中的内存泄漏
• vacuum 有时无法更新 relpages/reltuples
• SSI HOT 链遍历问题
• 附加到数据修改语句的 CTE 在使用规则时会失败（错误 6051）
• NOT VALID 约束没有正确地转储
• HS 从机无法很好地处理未记录的表（错误 6041）
• 使 DDL 命令支持 SSI
  • 修复的补丁（补丁中发现了问题，正在进行讨论和修改。）
• 数组上的域不再与 ANYARRAY 匹配
• contrib/citext 公开了排序规则代码中的实现缺陷（错误 6053）
• information_schema.element_types 视图定义中的错误（错误 5926）

Beta1 之前已解决的问题

• wal_buffers = -1 在重新加载时会导致虚假聊天
• 是否存在安全措施来防止恢复在达到一致性之前暂停？
• Walreceiver 在 AIX 上崩溃
  • Steve Singer 无法重现，建议这可能是人为错误
• 热备用反馈的错误
• GIST 重写与 pg_upgrade
• 需要更新 replication/README
• 后端错误地等待同步复制，即使 max_wal_senders = 0
• 重新加载配置文件不应导致服务器意外结束
• 修复 ecpg 预处理器回归
• 一旦 sync_standbys_defined 变成 true，就无法再变成 false。这不可能正确。
• 当 synchronous_standby_names 设置为 且配置文件重新加载时，后端不再需要等待复制。
• 需要在 recovery.conf.sample 中添加 pause_at_recovery_target
• BUG #5842：在获取结果切片时，PL/Python 中存在内存泄漏
• 需要在 protocol-replication.html 中解释热备用反馈消息
• 考虑将 ident 重命名为本地连接上的对等身份验证
• 多个备份导致严重问题
• FK 约束默认情况下为“NOT VALID”
• 在备用上 fsync=off 时，同步复制非常慢
• 启动时不再需要检查 synchronous_standby_names 和 max_wal_senders
• pg_last_xact_replay_timestamp 的限制
  • rhaas 说：不清楚这里是否有行动项目，因此将其移至已解决。如有更多详细信息，请随时移回。
• 要么完全删除 write_location，要么恢复破坏它的更改
  • write_location 问题的原始报告（但该电子邮件中的其他问题现在已修复）
  • 可能的补丁
• DO 块存在内存泄漏
• 复制超时
• 提高协议版本号
  • 尚未完成，会破坏某些东西
• 修复 attinhcount 跟踪
• SSI：pg_locks 中的 SIReadLock 行不显示 pid
  • 有人质疑是否应该在连接关闭后甚至可能在事务完成后抑制 pid
• synchronous_commit 和 synchronous_replication
• 从整数字面量转换为货币类型
• 关于 SQL/MED 对象的注释
  • rhaas 说：建议的补丁
  • rhaas 说：thom brown 指出 我忘记了用户映射
  • 修复用户映射会打开过大的问题
• SSI：由于竞争条件导致标记冲突时出现断言失败
  • 现有的补丁，在将共享 LW 锁换成排他锁后重新检查，应该可以解决
• 需要更新 keywords 表
• SSI：笨拙的错误处理导致显示通用消息，而不是包含提示的更具体的消息
• SSI：在子事务中禁用优化
• SSI：关于 SLRU 循环的 LOG 消息
• 同步复制和快速关闭
  • rhaas 说：没有简单的解决方案，我想我们现在就先放一放？
• SSI：三个不同的 HTAB 在共享内存中进行无序竞争
  • Heikki 建议“我们需要教 dynahash 在预分配后不要再分配任何条目。一个新的 HASH_NO_GROW 标志添加到 hash_create() 似乎是一个合适的接口。”
  • 或者，我们可以直接使用与最大条目匹配的初始分配，以确保所有 HTAB 至少可以分配配置的最大值。（为此有一个现有的补丁。）
  • 我提交了一个补丁来将新的标志添加到 hash_create() 中 - Heikki
• SSI：未能清理一些 SLRU 汇总的锁
  • 现有的补丁，正确设置了有问题的锁上的 commitSeqNo，应该可以解决
• ALTER TABLE ADD COLUMN 没有为继承子项创建 TOAST 表
• 类型化表 DDL 的一些遗漏
• 各种排序规则问题
  • 快完成了...
• pl/python 追踪修复
• 除非您执行 vacuum，否则不会使用 gin 索引
• SSI：在 RAM 磁盘数据库上进行高竞争 UPDATE 负载会使非可序列化事务的执行速度降低千分之几
  • 或者提高千分之几的速度。无论哪种方式，它都太接近于从噪声中分离出来。
  • 为了防止在极端高竞争负载下出现任何性能下降，如果不存在可序列化事务，则可能值得快速返回（不获取任何锁）。
• SSI：UPDATE 设置 TOASTed 值已损坏，无论事务隔离级别如何
  • 建议的补丁
• 外部表权限问题
• CREATE TABLE IF NOT EXISTS 不起作用
• 类型化表的补丁破坏了 pg_upgrade
  • 建议的补丁（tt2v2-binary-upgrade.patch）