/* * We do a concurrent index build by first inserting the catalog entry for the * index via index_create(),marking it not indisready and not indisvalid. * Then we commit our transaction and start a new one,then we wait for all * transactions that Could have been modifying the table to terminate. Now * we kNow that any subsequently-started transactions will see the index and * honor its constraints on HOT updates; so while existing HOT-chains might * be broken with respect to the index,no currently live tuple will have an * incompatible HOT update done to it. We Now build the index normally via * index_build(),while holding a weak lock that allows concurrent * insert/update/delete. Also,we index only tuples that are valid * as of the start of the scan (see IndexBuildHeapScan),whereas a normal * build takes care to include recently-dead tuples. This is OK because * we won't mark the index valid until all transactions that might be able * to see those tuples are gone. The reason for doing that is to avoid * bogus unique-index failures due to concurrent UPDATEs (we might see * different versions of the same row as being valid when we pass over them,* if we used HeapTupleSatisfiesVacuum). This leaves us with an index that * does not contain any tuples added to the table while we built the index. * For a concurrent build,it's important to make the catalog entries * visible to other transactions before we start to build the index. That * will prevent them from making incompatible HOT updates.The new index * will be marked not indisready and not indisvalid,so that no one else * tries to either insert into it or use it for queries. */
普通的create index是当建index时，不充许对表进行更改，postgresql支持的Concurrent创建index，是充分在建索引时同时对表进行更改。
共用了三个事务。
第一个事务，只是在系统表中增加索引定义，不建索引，索引不能insert,也不能select
第二个事务，创建索引，创建过程中充许对表insert/update/delete，提交时，索引可以insert，不能select.
第三个事务，把第二个事务过程中，没加入索引中的，合并进索引。
http://www.postgresql.org/docs/9.1/static/sql-createindex.html#SQL-CREATEINDEX-CONCURRENTLY
