KingbaseES V8R6 创建索引create index concurrently被阻塞
前言
CREATE INDEX CONCURRENTLY(CIC)是DBA们最常用的语句之一，它的好处是不阻塞DML语句。
但在大事务、长事务较多的系统，它可能被阻塞得很久。
本篇就从这个阻塞的案例开始，学习CIC的过程、原理以及注意事项。
测试CREATE INDEX CONCURRENTLY被阻塞
create table test(id int);
INSERT INTO test(id) VALUES (generate_series(1, 100000));
create table tmp(a int);
insert into tmp values(1);
会话1：
TEST=# select sys_backend_pid();
sys_backend_pid
-----------------
11860
(1 row)
select count(*) from test a, test b;
会话2:
create index concurrently ind_02 on tmp(a);
可以看到，即使test和tmp都不是同一个表，会话1执行的不是dml语句，tmp的索引创建依然被阻塞了。如果会话1中是要执行漫长的查询，会话2的索引创建也将一直被阻塞。
那么为什么被阻塞呢？
查看等待事件：
TEST=# SELECT pid, locktype,virtualxid,relation::regclass, mode FROM sys_locks where granted='f' order by pid;
pid | locktype | virtualxid | relation | mode
-------+------------+------------+----------+-----------
15150 | virtualxid | 6/5220 | | ShareLock
(1 row)
TEST=#
TEST=# SELECT pid, locktype,virtualxid,relation::regclass, mode FROM sys_locks where granted='t' order by pid;
pid | locktype | virtualxid | relation | mode
-------+------------+------------+-----------+--------------------------
11860 | relation | | test | AccessShareLock
11860 | virtualxid | 6/5220 | | ExclusiveLock
15150 | virtualxid | 7/1604 | | ExclusiveLock
15150 | relation | | tmp | ShareUpdateExclusiveLock
15440 | virtualxid | 8/659 | | ExclusiveLock
15440 | relation | | pg_locks | AccessShareLock
15440 | relation | | sys_locks | AccessShareLock
(7 rows)
当执行查询语句或dml时会获取一个virtualxid，但为什么创建索引要跟它获取同一个virtualxid？
先看看执行的函数堆栈，pid15150是被阻塞的pid，从堆栈中看到它正常获取一个锁WaitOnLock，锁类型是VirtualXactLock，并发现DefineIndex需要调用一个函数叫WaitForOlderSnapshots，它在等更旧的快照。
pid 15150：
gdb)
#0 0x00007f3f980917d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x00000000007f5ed3 in WaitEventSetWait ()
#2 0x00000000007f67b4 in WaitLatchOrSocket ()
#3 0x0000000000803ac5 in ProcSleep ()
#4 0x0000000000801362 in WaitOnLock ()
#5 0x0000000000802abf in LockAcquireExtended ()
#6 0x0000000000803242 in VirtualXactLock ()
#7 0x000000000062bd90 in WaitForOlderSnapshots ()
#8 0x000000000062fbf4 in DefineIndex ()
#9 0x000000000081ed29 in ProcessUtilitySlow ()
#10 0x000000000081f5ed in standard_ProcessUtility ()
#11 0x00007f3f909a95f9 in synonym_ProcessUtility () from /home/kingbase7/KESRealPro/V008R006C007B0012/Server/lib/synonym.so
#12 0x00007f3f907346a2 in plsql_utility_command () from /home/kingbase7/KESRealPro/V008R006C007B0012/Server/lib/plsql.so
#13 0x00007f3f8ffd70d4 in forceview_ProcessUtility () from /home/kingbase7/KESRealPro/V008R006C007B0012/Server/lib/force_view.so
#14 0x00007f3f8fdca8d6 in flashback_ProcessUtility () from /home/kingbase7/KESRealPro/V008R006C007B0012/Server/lib/kdb_flashback.so
#15 0x00007f3f8e73886b in pgss_ProcessUtility () from /home/kingbase7/KESRealPro/V008R006C007B0012/Server/lib/sys_stat_statements.so
#16 0x000000000081ac06 in PortalRunUtility ()
#17 0x000000000081c0bf in PortalRunMulti ()
#18 0x000000000081c979 in PortalRun ()
#19 0x00000000008174e2 in exec_simple_query ()
#20 0x000000000081a486 in PostgresMain ()
#21 0x000000000079fd2a in PostmasterMain ()
#22 0x00000000006eb5bf in main ()
pid 11860：
(gdb) bt
#0 0x00007f3f980917d3 in __epoll_wait_nocancel () from /lib64/libc.so.6
#1 0x00000000007f5ed3 in WaitEventSetWait ()
#2 0x00000000006da195 in secure_read ()
#3 0x00000000006e5824 in pq_recvbuf ()
#4 0x00000000006e5cb7 in pq_getbyte ()
#5 0x0000000000819a16 in PostgresMain ()
#6 0x000000000079fd2a in PostmasterMain ()
#7 0x00000000006eb5bf in main ()
可以看出进行select读操作，并获取buffer信息等，pq_getbyte描述了I/O读的操作。
sys_index表中的字段含义
indislive为true：表示索引可见，新事务知道这个索引存在。
indisready为true：表示该索引可写，新事务的DML操作需要维护该索引。
indisvalid 为true：表示改索引可读，新事务可以使用此索引进行查询。
CIC创建过程
阶段1
语法解析和预检查
构建catalog元数据信息, 主要包括 relcache，sys_class, sys_index，此时的状态是（indislive=true 索引可见、indisready=false不能被写入、indisvalid= false不能被查询）
获取一个锁（ShareUpdateExclusiveLock），避免创建阶段，表被删除。此阶段后，新事务会看到表中有一个invalid索引（但此时不可读写），
阶段2
1、获取ShareLock，等待此创建索引的表上所有的dml事务结束。
2、获取快照，对该表进行全表扫描，将对此快照可见的所有元组构建索引。
在这个阶段，其它事务对该表进行写入时，并不维护索引（因为索引还不能写入），仅保证HOT更新满足新索引定义，因此会有索引和表数据不一致的情况。
3、更新sys_index中indisready=true，此阶段后，索引可写入但不能查询（因为数据还不一致），其他事务修改该表时，需要维护新索引。
阶段3
第三阶段就是保证数据一致性。
使用ShareLock等待表上所有的dml事务结束，等待原因：阶段2中结束前开始的事务，无法看到新索引已变为可写状态，修改基表时并不维护新索引。
再次获取快照，进行一次全表扫描，将Phase2事务开始到现在索引中缺少的元组添加到索引中。
记下当前快照的xmin，获取所有早于当前快照xmin的快照的virtualxid，等待所有旧读写事务结束（我们的例子就卡在这步）
等待原因：旧事务的快照可以看到比构建索引时的快照更旧的行，如果它们使用新索引进行查询，会发生索引中查不到想要的旧数据，导致数据不一致。
因此，第3阶段必须等所有旧读写事务结束，才能将新索引置为可读状态。而后，更新relcache，释放锁ShareUpdateExclusiveLock。
CIC的注意事项
不要在有长事务时执行此操作，否则会等待很久。
CIC需要扫描两遍表，如果原表很大，耗时会更长，资源消耗更多。
分区表不支持在主表CIC创建索引，在子分区创建支持。
