sql - `lock_timeout` 是 Postgres CREATE INDEX CONCURRENTLY 所必需的吗

Question

运行 CREATE INDEX CONCURRENTLY 时，是否可以在获取 SHARE UPDATE EXCLUSIVE 时锁定表？如果需要 10 分钟来获取锁，是否会阻止任何人在此期间使用该表？

运行 CONCURRENTLY 的目的是安全地将索引添加到事件表。但是我找不到明确的答案是获取初始锁是否会导致查询排队。

特定安全 postgres 迁移库的文档提到 ( https://github.com/doctolib/safe-pg-migrations#user-content-safe_add_remove_index ):

If you still get lock timeout while adding / removing indexes, itmight be for one of those reasons:

• Long-running queries are active on the table. To create / remove an index, PG needs to wait for the queries that are actually running tofinish before starting the index creation / removal. The blockingactivity logger might help you to pinpoint the culprit queries.
• A vacuum / autovacuum is running on the table, holding a ShareUpdateExclusiveLock, you are most likely out of luck for thecurrent migration, but you may try to optimize your autovacuumssettings.

但即便如此也不能清楚地告诉我 - 如果我不设置超时(所以超时是0)，我等了很长时间获得锁 - 这会导致其他查询等待直到获得锁，还是 ADD INDEX 是这段时间内唯一被阻止的事情？

Answer 1

它将阻止 ShareUpdateExclusive blocks 的东西.但不是普通的 SELECT、INSERT、UPDATE、DELETE。

它阻止的最麻烦的事情可能是 ANALYZE。如果统计数据太过时且无法修复，您的 SELECT 可能会开始选择荒谬的计划，尽管没有被正式阻止，但这些计划永远不会完成。

它确实必须暂时获得比 ShareUpdateExclusive 更强的锁，但如果它必须等待它们，它会以不阻塞其他方式的间接方式进行。