【发布时间】:2018-02-09 17:13:31
【问题描述】:
在 PostgreSQL 中 CREATE INDEX CONCURRENTLY “挂起”的原因是什么,即它似乎永远不会完成? “从不”是指在 24 小时内它还没有完成。以下是详细信息。
我有这张桌子:
Table "public.user_verifying_attempts"
Column | Type | Modifiers
-----------------+-----------------------------+--------------------
user_id | integer | not null
type | userverificationtype | not null
value | text | not null
code | character(10) | not null
attempts | integer | default 0
emails_sent | integer | not null default 0
last_email_sent | timestamp without time zone |
它有大约 750 万行。我正在尝试通过将此语句提交到控制台(psql)来创建索引:
create index concurrently user_verifying_attempts_code_value_idx on user_verifying_attempts (code)';
我没有看到这个索引创建等待“Idle in Transaction”进程的证据,我也没有看到pg_stat_activity 中任何相关的证据。
此外,我实际上在本周早些时候以这种方式在我们的生产数据库的副本上创建了这个索引,并在大约 90 年代完成。这与我上周在一个不同但稍大的表上创建的另一个索引一致,无论是在生产上还是在副本上。这些信息给我的是一个粗略的数量级估计,我应该等待多长时间。分钟,绝对。几个小时,也许。但是,天?一定有问题。
最后,我将maintenance_work_mem 从默认的 16MB 设置为 1GB(主机有 ~160GB 内存)。
【问题讨论】:
-
您仍然应该看到
pg_stat_activity中的create index查询index concurrently在FWIW 的其他查询中“退居二线”。也许其他一些连接在表上有锁,因此无法应用或有些奇怪? -
我相信你。然而,我在
pg_stat_activity中看不到任何东西,其query字段具有create index...,我也看不到在锁定user_verifying_attempts表的pg_locks中。 -
呃。我认识到用这么少的信息很难诊断。我很欣赏这些尝试。无论如何,我刚刚杀死了我的
psql会话,创建了一个新会话,然后重新尝试。它在 70 年代完成。我很困惑,但很高兴有我的索引。我可能会删除这个问题,因为它不是很有用。 -
感觉好像网络连接丢失或发生了什么奇怪的事情。哦,好吧。
-
我知道这是一个老问题,但是如果您在
psql运行时在pg_stat_activity中看不到任何内容,那么这意味着 postgresql 杀死了您的会话,但是您的psql没有反应那。可能有几个原因:1.psql中的错误(可能但不太可能),2. 网络问题,很可能,特别是如果您通过错误配置的代理连接到数据库。但即使没有代理仍有可能。无论如何总是检查pg_stat_activity。
标签: postgresql