create index concurrently
用于在不阻塞DML操作的情况下创建索引。
Phase 1
开启事务 tx1。
插入relcache，插入索引相关元数据pg_class… ，和普通建索引相同，只是其中 pg_index 的 indisvalid、indisready设置为false。
在表上 加一个 session-level ShareUpdateExclusiveLock，加锁目的是防止在建索引的流程中表和索引元数据被其他流程修改。
提交事务 tx1。tx1 提交后，新开启的事务将会看到索引信息，索引状态为不可读(indisvalid = false)、不可写(indisready = false)，看到索引元数据的事务在插入数据时会考虑HOT-safe。
Phase 2
开启事务 tx2。
等待当前在执行的DML事务结束。具体实现是：找出当前所有持有的锁与ShareLock冲突的事务ID，等待这些事务提交或者Abort 。这一步等待的目的是什么？举例：表有两列{id, name}，数据如图-6所示，在id字段建索引。在Phase 1结束前开始的事务tx，无法看到索引元数据，所以在更新数据时做HOT update；Case1：由于流程中没有等待事务结束，建索引流程扫描heap tuple时，对应的heap tuple 为{id：3，name: ‘dd’}，index中对应的key是3，tx在索引扫描完后更新{id：3，name: ‘dd’} 这行数据为 {id：4，name: ‘dd’}，因此索引中的数据实际是错误的。普通建索引流程，因为阻塞DML操作，因此不会出现该问题。Case2：如果 tx是一个在Phase 1之后开启的事务，由于索引元数据可见，update操作发现对应的列上有索引，在更新数据时不会知道这不是一个HOT update，此时因为建索引和update的执行顺序，也会出现索引数据遗漏，索引数据如图-7所示。由于现在索引本身还是一个中间状态，对读写操作都不可见，所以这里数据有偏差不是什么大问题，只需要最终索引数据正确即可。Case2索引数据出现的遗漏，会在Phase 3中补全；而Case1出现的错误不会被修复，因为一条hot-chain上的所有tuple只会有一个index entry。
获取快照 snapshot1。
扫描表中的所有可见元组，构建索引。
设置索引的 indisready为true（索引对写操作可见）。
提交 tx2。tx2提交后新开启的事务更新数据时，会同时更新索引。
Phase 3
开启事务 tx3。
等待当前在执行的DML事务结束。这里时为了等待Phase 2结束前开始的事务，这些事务看不到索引indisready = true，在更新数据时没有更新索引。
获取快照 snapshot2。
为Phase2开始后没有更新索引的DML操作执行索引更新。validate_index
记录 snapshot2’s 中的xmin。
提交事务 tx3。
Phase 4
开启事务 tx4。
等待Phase 3之前开启的事务结束，这些事务可能持有一个比较老的snapshot，如果不等待这些事务结束就将索引的indisvalid 设置为true，这些事务可能出现读不一致的情况。如图-8所示，事务 txA 在Phase 3之前开启，读取数据r1，紧接着 txB delete r1；Phase 3中tx3 执行建索引时，由于对应的数据删除了，因此索引中没有r1的记录，tx3提交后索引的indisvalid设置为true，索引读可见，t’xA第二次读数据时使用索引，发现没有对应的数据，出现数据读一致的情况。为防止这种情况，需要在把索引的indisvalid设置为true之前，等待这些事务结束。
将索引的indisvalid 设置为true。
提交 tx4。
原文链接：https://blog.csdn.net/enmotech/article/details/119362121
