删除索引锁
我的Postgres版本是9.6
今天，我尝试使用以下命令从数据库中删除索引：
drop index index_name;它导致了很多锁-整个应用程序都被卡住了，直到我杀死了drop的所有会话(为什么它被分成几个会话？)。
当我检查锁时，我看到几乎所有被阻塞的会话都执行该查询：
SELECT a.attname, format_type(a.atttypid, a.atttypmod),
pg_get_expr(d.adbin, d.adrelid), a.attnotnull, a.atttypid, a.atttypmod
FROM
pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
WHERE a.attrelid = <index_able_name>::regclass
AND a.attnum > 0 AND NOT a.attisdropped
ORDER BY a.attnum;这会阻止系统操作，这有意义吗？
因此，我决定删除索引with concurrently选项，以防止锁。
drop index concurrently index_name;我现在从PGAdmin执行它(因为你不能从noraml transaction运行它)。
它运行了20分钟，但还没有完成。索引大小为20MB+-。
当我检查数据库中的锁时，我看到该表上有一个select查询，这会阻塞drop命令。
但是当我在另一个会话中执行这个select和execute时--这是非常快的(2-3)秒。
那为什么会阻止我的投递呢？还有没有别的选择呢？也许可以禁用索引？
回答 1
Stack Overflow用户
发布于 2018-06-11 05:02:56
drop index和drop index concurrently通常都是非常快的命令，但是和所有的DDL命令一样，它们都需要对表的独占访问权。
它们的不同之处只在于他们如何尝试实现这种独占访问。普通的drop index会简单地请求表上的排它锁。这将阻塞在drop查询开始之后尝试使用表的所有查询(甚至是selects)。它将一直这样做，直到它将获得独占锁-所有以任何方式接触该表的事务都将完成，并且使用drop的事务被提交。这解释了应用程序停止工作的原因。
concurrently版本还需要简短的独占访问权限。但它的工作方式不同-它不会阻塞表，而是等到没有其他查询接触到它，然后执行其(通常是简短的)工作。但如果桌子总是很忙，它就永远找不到这样的时刻，并无休止地等待着它。此外，我认为它只是尝试每X毫秒重复锁定表一次，直到成功为止，因此以后的并行执行可能更幸运，完成得更快。
如果您看到多个并发会话试图删除一个索引，而您并没有预料到这一点，那么您的应用程序中就存在一个bug。数据库本身永远不会做到这一点。
https://stackoverflow.com/questions/50782987
复制相似问题
腾讯云开发者
