索引访问方法必须支持多个进程对索引的并发更新。在索引扫描期间，PostgreSQL 核心系统在索引上抓取 AccessShareLock ，并且在更新索引期间(包括 VACUUM)也会抓取 RowExclusiveLock 。因为这些锁类型不会冲突，所以访问方法有责任处理任何它自己需要的更细致的锁需求。把整个索引锁住的排他锁只是在创建和删除索引或者 REINDEX, VACUUM FULL 的时候使用。
创建一个支持并发更新的索引类型通常要求对所需的行为进行广泛的并且细致的分析。对于 b-tree 和 Hash 索引类型，你可以读取在 src/backend/access/nbtree/README 和 src/backend/access/hash/README 里面描述的设计决策。
除了索引自己内部的一致性要求之外，并发更新创建了一些有关父表(堆)和索引之间的一致性问题。因为 PostgreSQL 是把堆的访问和更新与索引的访问和更新分开的。用下面的规则处理这样的问题：
在制作一行的索引记录之前，先做堆记录。因此并发的索引扫描很可能看不到堆记录。这么做应该是 OK 的，因为索引读者应该堆为提交的行不感兴趣。不过需要看看节49.5。
如果一条堆记录要被删除(被 VACUUM)，所有其索引记录都必须首先删除。
对于并发索引类型，一次索引扫描必须在保存有 amgettuple 最后返回的索引页面上维护一个销，而 ambulkdelete 不能删除其它后端用销固定的索引页面里面的记录。为何需要这条规则在下面解释。
没有第三条规则，如果一个索引是并发的，那么一个索引读者是可能在一条索引记录被 VACUUM 删除之前看到它的，然后在 VACUUM 删除它之后找到其对应的堆记录。如果读者到达该项时，该项编号仍然没有使用，那么这种情况不会导致严重的问题，因为空的项槽位会被 heap_fetch() 忽略。但是如果第三个后端已经为其它什么东西复用了这个项槽位又如何?如果使用 MVCC 兼容的快照，那么就不会有问题，因为新占据的槽位当然是太新了，因而无法通过快照测试。但是，对于非 MVCC 兼容的快照(比如 SnapshotNow)，那么就有可能接受并返回一个实际上并不匹配扫描键字的行。可以通过要求扫描键字在所有场合下都重新检查的方法来避免这种情况，但是这种方法开销太大了。取而代之的是，通过在索引页面上使用一个销，当作一个代理，告诉系统说，读者可能还在对应堆记录的索引记录上空"飞行"。在这样的销上面进行 ambulkdelete 块确保 VACUUM 无法在读者完成读取之前删除堆记录。这种解法增加了一点点运行时开销，而只是在非常罕见的实际有冲突的情况下才导致阻塞开销。
这个解决方法要求索引扫描必须是"同步的"：必须在扫描完对应的索引记录之后马上抓取每个堆记录。这样的方案开销比较大，原因有若干个。而"异步的"扫描，可以先从索引里收集很多 TID ，然后再稍后的某时访问堆行，这样就会烧很多索引锁的开销，以及可以允许更有效的堆访问模式。但是按照上面的分析，在非 MFCC 兼容单块着上必须使用同步方法，而对使用 MVCC 快照的查询，使用异步扫描应该是可以实现的。
在 amgetmulti 索引扫描里，访问方法不需要保证在任何返回的行上保持一个销。毕竟，除了给最后一个行加销之外，也没法给其它的加。因此，只能在 MVCC 兼容的快照里使用这样的扫描。