并发创建Postgres索引时需要什么类型的锁？

Question

我知道并发创建索引时，只需要一个SHARE ShareUpdateExclusiveLock 锁。

但是，在进程一开始的一小段时间内是否需要更严格类型的锁定？或者整个操作只需要一个SHARE ShareUpdateExclusiveLock 锁？

我这么问是因为我想知道在同时创建索引时设置什么类型的超时是有利的。

Answer 1

好吧，当文档不够时，可以直接查看代码。我将提供已发布PostgreSQL 13.1（REL_13_1标签）的链接，以避免将来可能发生的行号更改。

我可能不会描述来自客户端的命令的整个代码路径。通过语法我们知道我们需要IndexStmt命令节点 - 并发和非并发创建索引的语法相同。一切有用的事情都将从ProcessUtilitySlow

在这里，在评论中case T_IndexStmt，可以找到问题的直接答案：

/*
 * .... To avoid lock upgrade hazards, it's
 * important that we take the strongest lock that will
 * eventually be needed here, so the lockmode calculation
 * needs to match what DefineIndex() does.
 */
lockmode = stmt->concurrent ? ShareUpdateExclusiveLock
    : ShareLock;

一般来说，PostgreSQL 在命令执行期间不会升级锁。并将采用最终需要的最坚固的锁。因为CREATE INDEX CONCURRENTLY它是ShareUpdateExclusiveLock. 不是SHARE问题中提到的锁。

但让我们继续阅读：

• 如果是分区表，find_all_inheritors将在继承者上获取相同的锁定模式。
• 可以transformIndexStmt找到一些锁定模式，但是NoLock和AccessShareLock- 它们比ShareUpdateExclusiveLock
• 我们DefineIndex看到另一个提醒：

     * To avoid lock upgrade hazards, that lock should be at least
     * as strong as the one we take here.

并决定再次采用 ShareUpdateExclusiveLock 进行并发构建。这部分代码明显很长（仍然不如规划器那么大），但可读。

我错过了什么？大概。因此，让我们构建带有-DLOCK_DEBUG调试锁定行为选项的 PostgreSQL，看看会发生什么：

./configure  --prefix=/home/melkij/tmp/pgdev/inst --enable-cassert --enable-debug CFLAGS="-ggdb -Og -g3 -fno-omit-frame-pointer -DLOCK_DEBUG" --enable-tap-tests
make -sj 4
make install
initdb ...
pg_ctl start ...
# then psql with follow commands
create table foo as select generate_series(1,1000) as id;
set trace_locks = true;
create index concurrently on foo (id);
select oid, relname, relkind from pg_class where oid in (16387,16393);
#  oid  |  relname   | relkind 
#-------+------------+---------
# 16387 | foo        | r
# 16393 | foo_id_idx | i

trace_locks会记录很多东西，但我们感兴趣的是：

[vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/62 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] AccessExclusiveLock
[vxid:3/62 txid:495] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/63 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/63 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] RowExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16387] ShareUpdateExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] RowExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] ExclusiveLock
[vxid:3/64 txid:0] [CREATE INDEX] LOG:  LockAcquire: lock [12664,16393] ExclusiveLock

lock [12664,16387]这里指的是数据库OID = 12664（pg_class OID = 16387这些行是从记录的LockAcquireExtended）。

所以，我们实际上只获取ShareUpdateExclusiveLock表本身。OID=16393与其他几个锁一起是该命令构建的索引。尽管该对象提到了重锁定级别，但它不会干扰其他查询。Create index concurrently命令专门设计用于在运行正常应用程序查询时安全工作。