51.4. 索引锁的考量

索引访问方法必须支持多个进程对索引的并发更新。在索引扫描期间， PostgreSQL 核心系统在索引上抓取 AccessShareLock， 并且在更新索引期间(包括 VACUUM)也会抓取RowExclusiveLock 。因为这些锁类型不会冲突，所以访问方法有责任处理任何它自己需要的更细致 的锁需求。在全部索引上的排他锁将只是在索引的创建、删除或REINDEX 的时候被使用。

创建一个支持并发更新的索引类型通常要求对所需的行为进行广泛并且细致的分析。 对于b-tree 和 Hash索引类型，你可以读取在src/backend/access/ nbtree/README和src/backend/access/hash/README里面的设计 决策。

除了索引自己内部的一致性要求之外，并发更新创建了一些有关父表(堆)和索引之 间的一致性问题。因为 PostgreSQL是把堆的访问和 更新与索引的访问和更新分开的,所以存在一些窗口，在这些窗口里索引可能会与堆 不一致。我们用下面的规则处理这样的问题：

• 在制作一行的索引记录之前，先做堆记录。（因此并发的索引扫描很可能看不 到堆记录。这么做应该是 OK 的，因为索引读者对未授权的行不感兴趣。不过 需要看看节49.5Section 51.5。）

• 如果一条堆记录要被删除(通过“清空”命令)，所有其索引记录都必须首先删除。

• 一次索引扫描必须在保存有amgettuple最后返回的索引页面上维护一个销， 而ambulkdelete不能删除其它后端用销固定的索引页面里面的记录。 下面会解释需要这条规则的原因。

没有第三条规则，如果一个索引是并发的，那么一个索引读者是可能在一条索引记 录被 VACUUM删除之前看到它的，然后在VACUUM删除它之 后找到其对应的堆记录。如果读者到达该项时，该项编号仍然没有使用，那么这种 情况不会导致严重的问题，因为空的项槽位会被 heap_fetch()忽略。 但是如果第三个后端已经为其它什么东西复用了这个项槽位又如何?如果使用MVCC 兼容的快照，那么就不会有问题，因为新占据的槽位当然是太新了，因而无法通过 快照测试。但是，对于非 MVCC 兼容的快照(比如 SnapshotNow)，那 么就有可能接受并返回一个实际上并不匹配扫描键字的行。可以通过要求扫描键字 在所有场合下都重新检查的方法来避免这种情况，但是这种方法开销太大了。取而 代之的是，通过在索引页面上使用一个销，当作一个代理，告诉系统说，读者可能 还在对应堆记录的索引记录上空"飞行"。在这样的销上面进行 ambulkdelete块确保 VACUUM 无法在读者完成读取之前删除堆记录. 这种解法增加了一点点运行时开销，而只是在非常罕见的实际有冲突的情况下才导致阻塞开销。

这个解决方法要求索引扫描必须是"同步的"：必须在扫描完对应的索引记录之后马上 抓取每个堆记录。这样的方案开销比较大，原因有若干个。而"异步的"扫描，可以先 从索引里收集很多 TID ，然后再稍后的某时访问堆行，这样就会烧很多索引锁的开 销，以及可以允许更有效的堆访问模式。但是按照上面的分析，在非 MVCC 兼容单块 着上必须使用同步方法，而对使用 MVCC 快照的查询，使用异步扫描应该是可以实现的。

在amgetmulti索引扫描里，访问方法不需要保证在任何返回的行上 保持一个销。毕竟，除了给最后一个行加销之外，也没法给其它的加。 因此，只能在MVCC兼容的快照里使用这样的扫描。