Postgresql - Index Access Method Interface Definition 索引访问方法接口定义（四）

Index Locking Considerations

索引访问方法必须通过多个进程来处理索引的并发更新。核心PostgreSQL系统在索引扫描期间获取索引上的访问共享锁，并在更新索引（包括纯真空）时获取RowExclusiveLock。由于这些锁类型不冲突，所以访问方法负责处理可能需要的任何细粒度锁定。在索引创建、销毁或重新索引期间，将只对索引进行整体锁定。

构建支持并发更新的索引类型通常需要对所需行为进行广泛而精细的分析。对于B-树和哈希索引类型，您可以阅读有关src/backend/access/nbtree/README and src/backend/access/hash/README中涉及的设计决策。

除了索引本身的内部一致性要求外，并发更新还创建了父表（堆）和索引之间的一致性问题。因为PostgreSQL将堆的访问和更新从索引中分离出来，所以存在索引可能与堆不一致的窗口。我们用以下规则处理这个问题：

• 在生成索引条目之前，新建一个堆条目。（因此，并发索引扫描很可能看不到堆条目。这是可以的，因为索引阅读器无论如何都不会对一个未提交的行感兴趣。
• 当要删除堆条目（通过真空）时，必须首先删除所有索引条目。
• 索引扫描必须保持索引页上的一个PIN，保存由AgGuttuple最后返回的项，并且AdvkDebug不能从其他后端被钉扎的页面中删除条目。

如果没有第三条规则，索引读取器就可以在真空被移除之前看到索引条目，然后在真空中移除索引堆之后就可以到达相应的堆条目。如果读取器中的项目号仍然未被使用，这不会造成严重的问题，因为空项目时隙将被heap_fetch()忽略。但是如果一个第三的后端已经重新使用了项目插槽来做别的事情呢？当使用符合MVCC的快照时，没有问题，因为新的占用者的时隙必然太新，无法通过快照测试。然而，使用非MVCC兼容的快照（例如SnapshotAny），可以接受并返回实际上不匹配扫描键的行。我们可以通过在所有情况下要求扫描键对堆行进行检查来防御这种情况，但代价太高。相反，我们在索引页上使用PIN作为代理，以指示读取器仍然可能是从索引条目到匹配堆条目的““in flight”。在这样的PIN上制作ambulkdelete确保了在读取器完成之前，VACUUM不能删除堆条目。该解决方案在运行时间上花费很少，并且仅在很少发生冲突的情况下增加阻塞开销。

这个解决方案要求索引扫描是“同步的”：我们必须在扫描相应索引条目后立即获取每个堆元组。由于一些原因，这是昂贵的。一个“异步”扫描，我们从索引中收集许多TIDS，并且仅在某个时候访问堆元组，这需要更少的索引锁定开销，并且可以允许更高效的堆访问模式。根据以上分析，我们必须使用非MVCC兼容快照的同步方法，但是异步扫描对于使用MVCC快照的查询是可行的。

在amgetbitmap索引扫描中，Access方法不在任何返回的元组上保持索引PIN。因此，只有使用MVCC兼容的快照才能使用这种扫描。

当未设置Apple锁标志时，在可序列化事务中使用该索引访问方法的任何扫描将在完整索引上获取非阻塞谓词锁。这将产生一个读写冲突，其中任何元组的插入由并发可序列化事务进入该索引。如果在一组并发可串行事务中检测到某些读写冲突模式，则可以取消其中一个事务以保护数据完整性。当标志被设置时，它指示索引访问方法实现细粒度谓词锁定，这将趋向于减少此类事务取消的频率。