支持的版本: 当前 (17) / 16 / 15 / 14 / 13
开发版本: 开发版
不支持的版本: 12 / 11 / 10 / 9.6 / 9.5 / 9.4 / 9.3 / 9.2 / 9.1 / 9.0 / 8.4 / 8.3 / 8.2 / 8.1

62.5. 索引唯一性检查 #

PostgreSQL 使用唯一索引强制执行 SQL 唯一性约束,这些索引不允许存在具有相同键的多个条目。支持此功能的访问方法将 amcanunique 设置为 true。(目前,只有 b-tree 支持它。)在强制执行唯一性时,不会考虑 INCLUDE 子句中列出的列。

由于 MVCC,始终需要允许在索引中物理存在重复条目:这些条目可能引用单个逻辑行的连续版本。我们实际想要强制执行的行为是,没有 MVCC 快照可以包含两个具有相同索引键的行。这可以分解为在将新行插入唯一索引时必须检查的以下情况:

  • 如果当前事务已删除冲突的有效行,则没问题。(特别是,由于 UPDATE 总是在插入新版本之前删除旧版本,这将允许在不更改键的情况下更新行。)

  • 如果冲突行是由尚未提交的事务插入的,则潜在的插入者必须等待以查看该事务是否提交。如果它回滚,则没有冲突。如果它在不再次删除冲突行的情况下提交,则存在唯一性违规。(实际上,我们只是等待其他事务结束,然后完全重做可见性检查。)

  • 类似地,如果冲突的有效行已被尚未提交的事务删除,则潜在的插入者必须等待该事务提交或中止,然后重复测试。

此外,在根据上述规则报告唯一性违规之前,访问方法必须立即重新检查要插入的行的活跃状态。如果它已提交为死行,则不应报告违规。(这种情况不会在当前事务刚创建行的一般场景中发生。但是,在 CREATE UNIQUE INDEX CONCURRENTLY 期间可能会发生。)

我们要求索引访问方法自行应用这些测试,这意味着它必须访问堆来检查任何显示具有重复键的行的提交状态(根据索引内容)。这无疑是不美观且非模块化的,但它节省了冗余工作:如果我们进行单独的探测,则查找冲突行的索引查找将在查找插入新行的索引条目的位置时基本上重复进行。更重要的是,除非冲突检查是插入新索引条目的一个组成部分,否则没有明显的方法可以避免竞争条件。

如果唯一约束是可延迟的,则会有额外的复杂性:我们需要能够为新行插入索引条目,但将任何唯一性违规错误延迟到语句结束甚至更晚。为了避免不必要的索引重复搜索,索引访问方法应在初始插入期间进行初步的唯一性检查。如果这表明绝对没有冲突的活动元组,我们就完成了。否则,我们计划在需要强制执行约束时进行重新检查。如果在重新检查时,插入的元组和具有相同键的其他元组都是活动的,则必须报告错误。(请注意,为此目的,“活动”实际上意味着“索引条目的 HOT 链中的任何元组都是活动的”。)为了实现这一点,aminsert 函数会传递一个 checkUnique 参数,该参数具有以下值之一

  • UNIQUE_CHECK_NO 表示不应进行唯一性检查(这不是唯一索引)。

  • UNIQUE_CHECK_YES 表示这是一个不可延迟的唯一索引,必须立即执行唯一性检查,如上所述。

  • UNIQUE_CHECK_PARTIAL 表示唯一约束是可延迟的。PostgreSQL 将使用此模式来插入每一行的索引条目。访问方法必须允许重复条目进入索引,并通过从 aminsert 返回 false 来报告任何潜在的重复项。对于返回 false 的每一行,将安排延迟的重新检查。

    访问方法必须识别任何可能违反唯一约束的行,但报告误报并不是错误。这允许在不等待其他事务完成的情况下进行检查;此处报告的冲突不被视为错误,稍后会重新检查,届时它们可能不再是冲突。

  • UNIQUE_CHECK_EXISTING 表示这是对报告为潜在唯一性违规的行的延迟重新检查。虽然这是通过调用 aminsert 实现的,但访问方法在这种情况不能插入新的索引条目。索引条目已经存在。相反,访问方法必须检查是否存在另一个活动的索引条目。如果存在,并且目标行仍然是活动的,则报告错误。

    建议在 UNIQUE_CHECK_EXISTING 调用中,访问方法进一步验证目标行是否确实在索引中存在条目,如果不存在则报告错误。这是一个好主意,因为传递给 aminsert 的索引元组值将已被重新计算。如果索引定义涉及并非真正不可变的函数,我们可能正在检查索引的错误区域。检查在重新检查中是否找到了目标行可以验证我们正在扫描与原始插入中使用的相同的元组值。

提交更正

如果您在文档中发现任何不正确、与特定功能的体验不符或需要进一步澄清的内容,请使用此表单报告文档问题。