48.4. 索引锁的考量

一个索引访问方法可以选择它是否支持多个进程对索引的并发更新。 如果该方法的 pg_am.amconcurrent 标志为真， 那么在索引扫描期间，PostgreSQL 核心系统在索引上抓取 AccessShareLock，以及在更新索引期间抓取 RowExclusiveLock。 因为这些锁类型不会冲突，所以访问方法有责任处理任何它自己需要的更细致的锁需求。 把整个索引锁住的排他锁只是在创建索引，删除索引，或者 REINDEX 的时候使用。 如果 amconcurrent 是假，PostgreSQL 仍然在索引扫描的时候抓取 AccessShareLock，但是它在任何更新的时候都抓取 AccessExclusiveLock。 请注意这样就隐含着索引扫描是只读的假设；一个可能在扫描期间修改索引的访问方法仍将需要并发扫描情况下自己实现锁机制。

要记住，一个后端自己的锁是不会自相冲突的；因此， 即使一个非并发的索引类型也必须准备处理后端在自己扫描某个索引的同时插入或者删除其中的条目的情况。 （这当然是支持一个使用该索引找到需要更新的行之 UPDATE 的必要条件。）

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

除了索引自己内部的一致性要求之外，并发更新创建了一些有关父表（堆） 和索引之间的一致性问题。因为 PostgreSQL 是把堆的访问和更新与索引的访问和更新分开的。 我们用下面的规则处理这样的问题：

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

• 如果一条堆记录要被删除（由 VACUUM）， 所有其索引记录都必须首先删除。

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

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

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

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